• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Paul Clapham
  • Jeanne Boyarsky
Sheriffs:
  • Ron McLeod
  • Frank Carver
  • Junilu Lacar
Saloon Keepers:
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Al Hobbs
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • fred rosenberger

Q 2 pg 744 Threads Doubt

 
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dear Friends,

I've some doubt in the Q2 of Threads which is given below:

Given:
public class Letters extends Thread {
private String name;
public Letters(String name) { this.name = name; }
public void write() {
System.out.print(name);
System.out.print(name);
}
public static void main(String[] args) {
new Letters("X").start();
new Letters("Y").start();
} }
We want to guarantee that the output can be either XXYY or YYXX, but never XYXY or any
other combination. Which of the following method definitions could be added to the Letters
class to make this guarantee? (Choose all that apply.)
A. public void run() { write(); }
B. public synchronized void run() { write(); }
C. public static synchronized void run() { write(); }
D. public void run() { synchronized(this) { write(); } }
E. public void run() { synchronized(Letters.class) { write(); } }
F. public void run() { synchronized(System.out) { write(); } }
G. public void run() { synchronized(System.out.class) { write(); } }
Answer:
E and F are correct. E and F both cause both threads to lock on the same object, which will
prevent the threads from running simultaneously, and guarantee XXYY or YYXX. It's a bit
unusual to lock on an object like System.out, but it's perfectly legal, and both threads are
locking on the same object.

My Question
How this definition of method run()(option E):
public void run() { synchronized(Letters.class) { write(); } }
would lock on System.out object?

Thanks & Regards,
Nitin
 
Ranch Hand
Posts: 324
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
can anyone explain why option b is wrong.
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The option b is wrong because it creates a synchronized block for individual objects. Both the thread hold a lock on different object and hence don't block each other.

Also in the option e, the thread is not holding a lock on System.out. It's holding a lock of System.out in the other option
synchronized(System.out){
...
}
 
Nitin Bhardwaj
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Amir,

Option B is wrong because one of the thread(of X and Y) can be in the middle of write() method, means would have just executed one System.out.print(name) statement when the other is selected to run by the processor and hence between XX or between YY you will have Y(or YY) or X(or XX) coming which will make the output other than XXYY or YYXX as desired.
Hope this helps.
Nitin
 
Nitin Bhardwaj
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dear Friends,
My Question is still unanswered !!
How this definition of method run()(option E):
public void run() { synchronized(Letters.class) { write(); } }
would lock on System.out object?

Regards,
Nitin
 
Ranch Hand
Posts: 637
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Nitin,


E. public void run() { synchronized(Letters.class) { write(); } }
F. public void run() { synchronized(System.out) { write(); } }



Option e locks on Class object {Letters.class} and option F locks on System.out object.
I think the answer is saying that we need to lock on the same object across threads [ in option e Letter.class is the same lock object for both the threads and in option f System.out is the common lock object] to achieve atomic operation.
Thanks
Deepak
 
Ranch Hand
Posts: 377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Deepak Jain:
I think the answer is saying that we need to lock on the same object across threads to achieve atomic operation.

Correct. The important point is that the threads use the same object.
 
Nitin Bhardwaj
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Deepak and Manfred !!
What I thought before was that we are locking System.out object because it is the object used inside write() method. But now after your replies I came to know that if we can synchronize(acquire lock) on a single unique object like Letters.class (which is just one object per JVM) then also only one Thread will be allowed to enter inside such a method.
Please confirm that what I've understood is right..
Regards,
Nitin
 
Deepak Jain
Ranch Hand
Posts: 637
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Rule of thumb:
Lock on the same object across threads to achieve atomic operation.

Thanks
Deepak
 
That feels good. Thanks. Here's a tiny ad:
the value of filler advertising in 2021
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic