• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Ranch Hand
Posts: 67
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 1558
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Gasan Guseynov
Ranch Hand
Posts: 67
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@Anayonkar Yes, Operator finished it's job, but it repeats the loop. And it can reach line 5 before the Machine will release lock.
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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

 
Anayonkar Shivalkar
Bartender
Posts: 1558
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 1558
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 67
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1558
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Ranch Hand
Posts: 451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1558
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic