This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hello, just finished ch.9, and did the self test. However i have some notes on this chapter:
1) page 759 it reads:
When the sleep or wait is over, or.... can only reenter the runnable state. It will go directly from waiting to running (well, ...).
I think there is a "not" missing here. It should read : It will not go directly from waiting to running....
2) Question 6, page 763
The answer that the book gives is A. However IMHO, A's explanation suffers from both "weird" wording, + i think B is more appropriate.
We know that a thread notifies another thread(s) on some object's lock. The thread(s) are notified (and it is also the threads who notify) and not the object.
But even after some other thread calls B.notify() while having possession of B's lock, then it is only after this other thread releases B's lock,
that thread A can resume execution, (or at least being considered for execution by the scheduler)
3) Question 15, page 769 (i answered this correctly, so i cant possibly be blamed for being revengeful LOL!!!)
Books says in the answer that with either answer the first output must be "yo". But with code fragment II, it is possible from thread t1
to execute line and set flag, then thread t2 comes in finds flag already set, gets in the loop and compares flag with its own thread id
and prints "dude". So the first output could be "dude".
Hello Achilleas...Excelent analysis! I am glad that this time our ideas and thoughts coincide! after that 'rifi-rafe' we had on chapter 10.
Be informed that Exam (Objective 4.4) - Wait And Notify- is NO longer in the exams, however it is good for us to be well equiped for our first job.
I am also convinced that option B is correct! here is my detailed explanation:
Page 760 Communicating with Objects by Waiting And Notifying:
"The notify() method is used to send a signal to one and only one of the threads that are waiting in that objects pool."
According to the self test question, we can observe that it is Thread A that is waiting in the B objects pool, so how can option A be correct? I think Bates has to help us here.
Study CAREFULLY the following code that I copied from page 748 of the K&B book (the ONLY modification I did was to invoke the wait method with arguments - b.wait(2000) -):
This analysis is to the best of my knowledge...
Take note: in the above code thread A is the main method, at line 6 it posseses the lock on object B, when it gets to line 9 it releases the lock, waits for two seconds or waits for the lock on B to be released before it can become a candidate to get another turn at the CPU. This CLEARLY tells us that option B of the Self Test is correct!.
I repeat it will be SURPRISING to me if option A of the Self Test is correct, that will mean that we have to study threads again or get further explanations from the authors.
I also agree with you on question 15 page 769, if both threads have concurrent access to the non-synchronized chat method, there's NO guarantee that line 8 will always return true -at the first instance-, hence there is a possibility that the first output is "dude".
In Your Pursuit Towards Certification, NEVER Give Up.