wood burning stoves 2.0*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Threads Lock aquisition Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Threads Lock aquisition" Watch "Threads Lock aquisition" New topic
Author

Threads Lock aquisition

Sanjeev Singh
Ranch Hand

Joined: Nov 01, 2006
Posts: 381
Below is a Question from K&B book.

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(); } }
[ November 16, 2006: Message edited by: Sanjeev Kumar Singh ]

~Sanjeev Singh<br />SCJP 1.5
Saurabh Vyas
Ranch Hand

Joined: Sep 02, 2003
Posts: 72
I guess C is the answer.

ie public static synchronized void run() { write(); }
Sanjeev Singh
Ranch Hand

Joined: Nov 01, 2006
Posts: 381
C is not a legal override so will not pass the compilation even.
:roll:
Saurabh Vyas
Ranch Hand

Joined: Sep 02, 2003
Posts: 72
I think you have already given the answer in the question.

If out of selection we have to select than I guess answers can be B and E both should work.

My previous answer was definitely wrong.
tc king
Greenhorn

Joined: Nov 10, 2006
Posts: 11
i think the answer can be E,F,G.Beacause the synchronized object is the same to two threads.
venkatesh pendharkar
Ranch Hand

Joined: Apr 29, 2006
Posts: 106
I dont think B is the correct answer because we are calling run on two different objects not on the same.
I think answer E & F are the only correct options.E bbecause by writing (Letters.class) we are synchronizing on the Letters class rather than any other object.So although different Letters object are accessing run() method it will be synchronized.
In option F,we are using System.out in synchronizing.Whlie starting any application JVM creates an object of PrintStream class & connects it to default o/p(console in our case) & this obejct is reffernced by System.out variable.Thus we are synchronizing on a single object for printing & hence will always be "xxyy" or "yyxx"
Option G is wrong beacuas (.class) can be used only on class name but not on any object & System.out represents an object.
Burkhard Hassel
Ranch Hand

Joined: Aug 25, 2006
Posts: 1274
Hi ranchers,

E and F are correct


A doesn't do, because there is no synchronization at all.

B doesn't do either. with a synchronized run method, you synchronze on this, i.e. the tread. With the two threads, each of them has an independent lock on itself.

C does not compile as you cannot override a nonstatic with a static method.

D doesn't do, because it's just the same as B.

E works fine. You synchronize on the class literal, that is shared by all objects of this class. Sync works. Each of the two thread objects has first to aquire a lock on that common object before it can run the synchronized block.

F works fine also. You synchronize on the out object, the output stream. So each thread must wait for the other to give up its lock to the output stream before it can print anything.

G does not compile. Only classes have this class literal, but not objects thereof. If it said synchronized(System.class) it would work, like with answer E.



By the way, you can test this all for yourself.
But you should put a yield(); between the two outputs of the write() method. Otherwise you may not see a difference between sync and no-sync. Also it would be nice to print more than just two letters, eg try this:





Yours,
Bu.


all events occur in real time
Sanjeev Singh
Ranch Hand

Joined: Nov 01, 2006
Posts: 381
Thanks Bu(rkhard),
Nice explanation.I was having a confusion on the last two options E and F.So the basic idea of this question is that both the threads have their own worksapce and they can not syncronize on this object.
Now I have changed the question a bit...Here is the modified one.


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(); } }

In this case what will be the answers?
[ November 17, 2006: Message edited by: Sanjeev Kumar Singh ]
Burkhard Hassel
Ranch Hand

Joined: Aug 25, 2006
Posts: 1274
Hi Sanjeev,

when extending Runnables you may synchronize the run method and all threads with this Runnable passed to their constructor will run one after another. So far it is ok.

But in your example, you should tick "Code does not compile".
The Runnable implementing class Letters does not have a parameterless constructor. So no compile.

But there's more wrong with the logic.
Making a thread with new Thread(le,"X") will pass a Runnable to the threads constructor, along with a name for the thread. But this "X" has nothing to do with the "name" field of the runnable.

If you have only one runnable object of class Letters, you can have only one name field. Either "x" or "y".


Yours,
Bu.
Sanjeev Singh
Ranch Hand

Joined: Nov 01, 2006
Posts: 381
Thanks Bu for locating the error.Here is the new Question.

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(); } }

In this case what will be the answers?

[ November 18, 2006: Message edited by: Sanjeev Kumar Singh ]
[ November 18, 2006: Message edited by: Sanjeev Kumar Singh ]
Burkhard Hassel
Ranch Hand

Joined: Aug 25, 2006
Posts: 1274
Hi, Sanjeev,

now it's perfect!

My proposals:

A no, no sync at all
B this works now. Now the two threads are synchronized on their common runnable named "le" from the main method. In the first example (above), the sync was on the different thread object. Now here the thread objects are independent, but the sync is on their common runnable.
C no compile again (non-static / static problem)
D also fine, because it's the same as B again.
E again ok, they are sync on the common class literal thing.
F ok, if you sync on the output stream there could be no mixing
G is again the same compiler error as above.


And again, if you cannot see any difference in the behaviour of method if it is synchronized or not, just put a Thread.yield(); in between the outputs of the names.

Nice question. Only K&B have such funny ideas like synchronizing on the System.out !



Yours,
Bu.
James Quinton
Ranch Hand

Joined: Oct 02, 2006
Posts: 94
It is a very nice question helping you understand that each Object has its only lock. However, this kind of code is practically useless, it's for academic purpose only.
Sanjeev Singh
Ranch Hand

Joined: Nov 01, 2006
Posts: 381
Thanks Bu,
B this works now. Now the two threads are synchronized on their common runnable named "le" from the main method. In the first example (above), the sync was on the different thread object. Now here the thread objects are independent, but the sync is on their common runnable.

This quote is most important.Though I had also concluded the same I want this to be confirmed from you/ranchers.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Threads Lock aquisition