I probably found a bug in a code on pages 750-751.
Here is my original post:
I'm reading Sierra & Bates SCJP 1.6 preparation book. In chapter 9: "Threads", i read this code illustrating wait\notify methods:
Idea is that Machine thread first gets to waiting state, then Operator notifies it, after that Machine wakes up, does it's job and then reacquiring the lock and goes to wait again, after that all repeats.
At least this is how it's written in the book.
But I thought about the following situation:
Let's imagine that on the first run Machine thread took a lot of time to Send machine steps to hardware (line 20), meanwhile Operator already done Get shape from user (line 4) and is ready to acquire the lock (line 5).
Right after the Machine exits synchronized block, Operator acquires the lock and Machine goes to blocking state. After that Operator calls notify (line 7), but Machine isn't waiting yet, it only tries to acquire the lock.
After the Operator releases the lock, the Machine goes to wait state, after that the Operator calculates new machine steps, notifies the Machine, it wakes up and does it's job. But, the previous Operator command
was lost, because the Machine didn't acquired lock in time and wasn't waiting.
Have I missed something or the specified code may result in the Operator command loss?
Please let me know if this is really as I explained and if it is, was it already found and if here already were a discussions on this, I would be very thankful if links to that posts will be provided.