About Question com.enthuware.ets.scjp.v6.2.750 :

Moderator: admin

Post Reply
ETS User

About Question com.enthuware.ets.scjp.v6.2.750 :

Post by ETS User » Tue Jan 11, 2011 8:24 pm

In which of the following cases a thread will definitely be alive but not be running?
Option a: The thread has issued a call to wait( ).
"In this situation, the thread will be blocked until some other thread calls notify()/notifyAll() on the object on which this thread has called wait()."

In this situation, isn't the thread alive bu not running? Why is this option not a correct selection?

thank you

Guest

Re: About Question com.enthuware.ets.scjp.v6.2.750 :

Post by Guest » Tue Jan 11, 2011 8:27 pm

Never mind. This you did select option A as a correct answer... :oops:

javatek202
Posts: 8
Joined: Tue May 14, 2013 12:27 am
Contact:

Re: About Question com.enthuware.ets.scjp.v6.2.750 :

Post by javatek202 » Wed Jul 10, 2013 5:32 pm

Your explanation to Option 2 when a thread is trying to enter a synchronized block and the monitor is not free:

"in this situation, the thread is blocked until some other thread calls to notify()/notifyAll() on the object whose synchronized block this thread is trying to enter"

is confusing, because this situation is a more general case which has nothing to do with wait() and notify().

The explanation should be: "the thread will be blocked until the currently executing thread (which owns the monitor lock) finishes executing the block and releases the lock".
(At this point the monitor is free so the thread may acquire the lock, so this is not related to wait()/ notify())

admin
Site Admin
Posts: 8621
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question com.enthuware.ets.scjp.v6.2.750 :

Post by admin » Wed Jul 10, 2013 5:37 pm

The currently executing thread may not necessarily be the one that owns the lock on which the thread in question is waiting on.

HTH,
Paul.
If you like our products and services, please help us by posting your review here.

javatek202
Posts: 8
Joined: Tue May 14, 2013 12:27 am
Contact:

Re: About Question com.enthuware.ets.scjp.v6.2.750 :

Post by javatek202 » Thu Jul 11, 2013 3:17 pm

Hi Paul,
Per JLS:
"A synchronized statement acquires a mutual-exclusion lock on behalf of the executing thread, executes a block, then releases the lock. While the executing thread owns the lock, no other thread may acquire the lock.

synchronized ( Expression ) Block

The type of Expression must be a reference type, or a compile-time error occurs.

A synchronized statement is executed by first evaluating the Expression.

If evaluation of the Expression completes abruptly for some reason, then the synchronized statement completes abruptly for the same reason.

Otherwise, if the value of the Expression is null, a NullPointerException is thrown.

Otherwise, let the non-null value of the Expression be V. The executing thread locks the lock associated with V. Then the Block is executed. If execution of the Block completes normally, then the lock is unlocked and the synchronized statement completes normally. If execution of the Block completes abruptly for any reason, then the lock is unlocked and the synchronized statement then completes abruptly for the same reason."

From these JLS quotes, the thread currently executing the synchronized block must own the lock of the object the block is synchronized on, and it is also the same lock that another thread blocked trying to enter this same synchronized block should be waiting for.

Please correct me if i am wrong and could you give an example where the thread currently executing a synchronized block may not necessarily own the lock of the object that the block is synchronized on.

admin
Site Admin
Posts: 8621
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question com.enthuware.ets.scjp.v6.2.750 :

Post by admin » Thu Jul 11, 2013 5:23 pm

What you are saying is correct but it is not what the explanation is talking about. For example, let's say thread three threads: T1, T2, T3. T1 acquires the lock for an Object O1 and then for some reason it is blocked (could be for I/O, or another lock). Now, T2 comes looking for the lock of O1 and gets blocked as well. Now, thread T3 is currently running. However, T3 is not the one that owns the lock that T2 is looking for.

Of course, T3 can't call notify on O1 but that is not what the explanation is saying. All it is saying is that from the perspective of T2, until some other thread calls notify on O1, it cannot move forward. The thread that must call notify() may not be the one that is currently running, so the statement that you wrote, i.e. the thread will be blocked until the currently executing thread (which owns the monitor lock) finishes executing the block and releases the lock" is not correct.

Hope it is clear now.
Paul.
If you like our products and services, please help us by posting your review here.

javatek202
Posts: 8
Joined: Tue May 14, 2013 12:27 am
Contact:

Re: About Question com.enthuware.ets.scjp.v6.2.750 :

Post by javatek202 » Fri Jul 12, 2013 4:33 pm

First I'm not trying to drill into this issue, I'm just trying to understand your explanation in the hope i can learn something more about threads synchronization.

So let's say we have this synchronized block B1 based on your example:

Object o1= new Object();
synchronized (O1) {
// block B1
}


You said in your example:
"there are three threads: T1, T2, T3. T1 acquires the lock for an Object O1 and then for some reason it is blocked (could be for I/O, or another lock). Now, T2 comes looking for the lock of O1 and gets blocked as well. Now, thread T3 is currently running. However, T3 is not the one that owns the lock that T2 is looking for..."

1. Are you saying T3 is currently executing the synchronized block B1? If so, T3 must own the lock for object O1.

2. Or you mean T3 is the currently running thread in the application ( not specifically running the block B1)? If so, i agree with your explanation.

3. Then I have another related question:
Lets say T1 owns lock O1 and is executing block B1 then T1 gets blocked on I/O. Does it release the lock O1?

4. if thread T1 does release the lock on O1 and thread T2 is trying to enter block B1, how does T2 know lock O1 is now free? ( i.e. does T1 has to call O1.notify()/notifyAll()? )

5. In the general case where a synchronized block completes either normally or abruptly, how do any competing threads trying to enter the block know the lock is now free? and how does the OS pick which thread to give the lock to so it can now run this synchronized block?

Thanks for your time.

admin
Site Admin
Posts: 8621
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question com.enthuware.ets.scjp.v6.2.750 :

Post by admin » Fri Jul 12, 2013 5:21 pm

javatek202 wrote: 1. Are you saying T3 is currently executing the synchronized block B1? If so, T3 must own the lock for object O1.
No.
2. Or you mean T3 is the currently running thread in the application ( not specifically running the block B1)? If so, i agree with your explanation.
Yes. It is just running some other irrelevant stuff.
3. Then I have another related question:
Lets say T1 owns lock O1 and is executing block B1 then T1 gets blocked on I/O. Does it release the lock O1?
No. The lock will not be released until T2 gets out of the synchronized block.
4. if thread T1 does release the lock on O1 and thread T2 is trying to enter block B1, how does T2 know lock O1 is now free? ( i.e. does T1 has to call O1.notify()/notifyAll()? )
No, if the lock is already free by the time T2 tries to acquire it, no notify is required. notify/notifyall are required when T2 tries to acquire a lock and the lock is not free. This causes T2 to be blocked. So now whoever owns the lock needs to call notify.
5. In the general case where a synchronized block completes either normally or abruptly, how do any competing threads trying to enter the block know the lock is now free? and how does the OS pick which thread to give the lock to so it can now run this synchronized block?

Thanks for your time.
When the thread that own the lock calls notifyAll and exits out of the synchronized block, the OS removes all the blocked thread (i.e. the threads that are blocked due to this particular lock being not available) from the wait queue and makes them ready to run. Now, they all again compete for the lock and whichever thread gets the lock, proceeds, while the others get blocked again.
If the thread that owns the lock calls notify (instead of notifyAll), the OS picks any one thread (which one, depends on the OS) and makes it ready to run.

HTH,
Paul.
If you like our products and services, please help us by posting your review here.

javatek202
Posts: 8
Joined: Tue May 14, 2013 12:27 am
Contact:

Re: About Question com.enthuware.ets.scjp.v6.2.750 :

Post by javatek202 » Mon Jul 15, 2013 6:04 pm

Hi Paul,

Thank you for your answers.
I am clear on your explanation for questions 1, 2 & 3.

For #4, you stated that:
notify/notifyall are required when T2 tries to acquire a lock and the lock is not free. This causes T2 to be blocked. So now whoever owns the lock needs to call notify. "
But this is only true if T2 has called o1.wait() , which it did not in your example.

According to the API doc for notify()/ notifyAll() and the JLS documentation for threads and Wait Sets and Notifications, notify() /notifyAll() only wakeup those threads who have called wait()

Quote from http://docs.oracle.com/javase/6/docs/api/ for java.lang.Object class:
public final void notifyAll()
Wakes up all threads that are waiting on this object's monitor. A thread waits on an object's monitor by calling one of the wait methods.
Quote from http://docs.oracle.com/javase/specs/jls ... l#jls-17.2
Every object, in addition to having an associated monitor, has an associated wait set. A wait set is a set of threads.

When an object is first created, its wait set is empty. Elementary actions that add threads to and remove threads from wait sets are atomic. Wait sets are manipulated solely through the methods Object.wait, Object.notify, and Object.notifyAll.


So should the answer for #4 be:
"T2 has to wait for whoever owns the lock to release the lock (by exiting it synchronized block)"

The same goes for your answer #5:
When the thread that own the lock calls notifyAll and exits out of the synchronized block, the OS removes all the blocked thread (i.e. the threads that are blocked due to this particular lock being not available) from the wait queue and makes them ready to run
Should we remove "calls notifyAll()", since the blocked thread in our example has not called wait(), hence it won't be affected by notify()

Lastly, could you look at some links below which discussed about notify/notifyAll only applies for "waiting" threads which have called wait(), not those blocked on lock or IO:

http://www.coderanch.com/t/418310/java- ... d-threads

http://www.coderanch.com/t/185099/java- ... fyAll-wait

Your explanations are very helpful for me to be clear on this small issue about threads blocked on lock.

I would like to get your confirmation about whether notify()/notifyAll() is required, if a thread trying to enter a synchronized block is blocked on the lock but not invoking wait() on the lock or it just needs to wait for whichever thread owning the lock to release it by exiting its synchronized method.

Thanks for your time.

admin
Site Admin
Posts: 8621
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question com.enthuware.ets.scjp.v6.2.750 :

Post by admin » Mon Jul 15, 2013 6:55 pm

You are right, my mistake. If wait() is not called, notify is not required.

thanks!
Paul.
If you like our products and services, please help us by posting your review here.

Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests