David Kay wrote:from what I can see there is no guarantee this code will execute correctly since the lock on the b object could be obtained by either of the threads which will block the other.
Here is how I am assuming it works:
- Thread b is started (line 4) which calls the run method of ThreadB in a separate thread of execution.
- The main thread continues and at the same time as the run method in ThreadB
which gets a lock on itself (the object b) by entering the synchronisation block (line 20).
- Meanwhile the main thread gets to line 6 but can't enter the synchronisation block because the other thread has a lock on it. So it waits.
Matthew Brown wrote:If you want to make the test more robust, I'd add a short sleep() before the second thread enters the synch block.
Jeff Verdegan wrote:... and I don't feel like doing that just now.
Now that we have java.util.concurrent...
Paul Clapham wrote:
Jeff Verdegan wrote:... and I don't feel like doing that just now.
because...
Now that we have java.util.concurrent...
In other words, "Now that I have this handy chain-saw, I don't really remember how to chop down a tree with a stone ax anymore." Unfortunately I don't think that wait() and notify() are going to be deprecated for quite a while, so people are still going to have to learn them in order to pass the exams.
Don't get me started about those stupid light bulbs. |