File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Probably found a bug in a code sample in Sierra & Bates SCJP 1.6 book (chapter 9 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Probably found a bug in a code sample in Sierra & Bates SCJP 1.6 book (chapter 9 "Threads", p. 750)" Watch "Probably found a bug in a code sample in Sierra & Bates SCJP 1.6 book (chapter 9 "Threads", p. 750)" New topic
Author

Probably found a bug in a code sample in Sierra & Bates SCJP 1.6 book (chapter 9 "Threads", p. 750)

Gasan Guseynov
Ranch Hand

Joined: Jan 03, 2006
Posts: 67
I probably found a bug in a code on pages 750-751.

Here is my original post:

Hi,

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.
Anayonkar Shivalkar
Bartender

Joined: Dec 08, 2010
Posts: 1512
    
    5

Gasan Guseynov wrote: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).

Well, when Machine reaches at line 20, it means that it has come out of wait state. It can come out of wait state only when someone (Operator) notifies it. Now, this means that Operator has already reached line 7.

Thus, at this point of time, Operator has finished its job, and it doesn't matter how much time Machine takes to send command to hardware.

I hope this helps.


Regards,
Anayonkar Shivalkar (SCJP, SCWCD, OCMJD, OCEEJBD)
Gasan Guseynov
Ranch Hand

Joined: Jan 03, 2006
Posts: 67
@Anayonkar Yes, Operator finished it's job, but it repeats the loop. And it can reach line 5 before the Machine will release lock.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 19070
    
  40

Gasan Guseynov wrote:@Anayonkar Yes, Operator finished it's job, but it repeats the loop. And it can reach line 5 before the Machine will release lock.



Yes, the way the code is written, it is possible to lose notifications when the machine releases the lock (without using the wait method). In fact, based on the amount of notifications being sent, it is highly likely. It is also highly likely that the operator sends many notification during its time slice -- meaning the machine gets more than one notification to wake up. These extra notifications will be lost too.

However, interestingly, it is also probably not a bug, but just very inefficient design -- since that operator sends so many notifications. My guess is that this section of the book is probably to show you the wait/notify mechanism, and not really how to use it correctly.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Anayonkar Shivalkar
Bartender

Joined: Dec 08, 2010
Posts: 1512
    
    5

Gasan Guseynov wrote:@Anayonkar Yes, Operator finished it's job, but it repeats the loop. And it can reach line 5 before the Machine will release lock.

Of course. But then, due to synchronization, Operator will wait till lock can be acquired. Machine will enter in wait state and release the lock. After that, operator acquires the lock, does its stuff and notifies the Machine and the flow continues.
Anayonkar Shivalkar
Bartender

Joined: Dec 08, 2010
Posts: 1512
    
    5

Henry Wong wrote:These extra notifications will be lost too.

Yes. This is why wait should be called upon a condition (instead of 'while true').

Practically, it is something like Operator would create a ready-to-process object and put it in a queue and notify the Machine. Further, Machine will process it, and will wait only if queue is empty, otherwise, Machine will keep on processing the objects.
Gasan Guseynov
Ranch Hand

Joined: Jan 03, 2006
Posts: 67
Probably I was to hurry to write a post, because a couple of pages later in a book there is some sort of clarification on that code regarding that problem and also there is provided a better version that addresses the problem. Probably, the only flaw I see now is that authors didn't aforementioned that the first code has a problem and they'll address that later.
Anayonkar Shivalkar
Bartender

Joined: Dec 08, 2010
Posts: 1512
    
    5

Gasan Guseynov wrote:Probably I was to hurry to write a post, because a couple of pages later in a book there is some sort of clarification on that code regarding that problem and also there is provided a better version that addresses the problem. Probably, the only flaw I see now is that authors didn't aforementioned that the first code has a problem and they'll address that later.

But you got the issue even before reading the next section, which is very good . Lot of people find it difficult to understand wait and notify properly
Helen Ma
Ranch Hand

Joined: Nov 01, 2011
Posts: 451
Hi, Gasan.
To understand more about wait/notify/notifyAll, I read How to Program Java by Deitel and Deitel. It has a very clear example on this.
For the exam, this objective is removed.
Anayonkar Shivalkar
Bartender

Joined: Dec 08, 2010
Posts: 1512
    
    5

Helen Ma wrote:For the exam, this objective is removed.

Really? So, what is it there for synchronization now? Locks from Concurrent package? wait/notify was a nice topic
Helen Ma
Ranch Hand

Joined: Nov 01, 2011
Posts: 451
Yes, before I took the exam, a lot of Java Ranchers said no wait/notify questions in the exam. That is true. As I remember, this objective is officially removed, just like object serialization which was removed.

There may be some synchronization questions without wait/notify involved.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Probably found a bug in a code sample in Sierra & Bates SCJP 1.6 book (chapter 9 "Threads", p. 750)