Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Thread doubt about wait and notify.  RSS feed

 
Josh Borg
Ranch Hand
Posts: 37
Chrome Eclipse IDE Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the following code, my doubt is if the method can notify(); be executed before p.wait(); (Productor class get the object lock first)
causing the code in the line of p.wait wait indefinitely for a notify command to make it continue.

 
Henry Wong
author
Sheriff
Posts: 23283
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Josh Borg wrote:In the following code, my doubt is if the method can notify(); be executed before p.wait(); (Productor class get the object lock first)
causing the code in the line of p.wait wait indefinitely
for a notify command to make it continue.


Yes. That race condition is possible.

Henry
 
Josh Borg
Ranch Hand
Posts: 37
Chrome Eclipse IDE Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry Wong wrote:

Yes. That race condition is possible.

Henry


What's the possibility? Solution?
 
Henry Wong
author
Sheriff
Posts: 23283
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Josh Borg wrote:
What's the possibility? Solution?


The possibility depends on the JVM. For a modern Windows based JVM, sitting on a unstressed machine with multiple cores, I would say that the likelihood of it happening is close to zero.

On a JVM running on an OS where the scheduler gives more priority to starting threads, with only one core, or having it stressed with running other tasks, sure, it can be very possible.


The solution ??

1. Never go into the waiting state blindly. Use some sort of state flag.
2. Never assume that the state is correct upon waking up. Check that state flag. This also means that the wait() method call will likely have to be in a loop.

and of course,

3. Correctly synchronize the code to protect the state flag. Synchronization is not simply to avoid an illegal monitor state exception when wait() or notify() is called. You have thread communication happening, so correctly protect it.

Henry
 
Josh Borg
Ranch Hand
Posts: 37
Chrome Eclipse IDE Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry Wong wrote:
Josh Borg wrote:
What's the possibility? Solution?


The possibility depends on the JVM. For a modern Windows based JVM, sitting on a unstressed machine with multiple cores, I would say that the likelihood of it happening is close to zero.

On a JVM running on an OS where the scheduler gives more priority to starting threads, with only one core, or having it stressed with running other tasks, sure, it can be very possible.

1. Never go into the waiting state blindly. Use some sort of state flag.
2. Never assume that the state is correct upon waking up. Check that state flag. This also means that the wait() method call will likely have to be in a loop.

and of course,

3. Correctly synchronize the code to protect the state flag. Synchronization is not simply to avoid an illegal monitor state exception when wait() or notify() is called. You have thread communication happening, so correctly protect it.

Henry


Okay, thanks Henry, but why it's near than zero the possibility of it happens? There is not so few code in productor's run that we can't assure that the run will not get the lock first?


For anyone that is disposed to help, how I do it in this code for example, I don't have idea, maybe a boolean and a conditional statement?

Never go into the waiting state blindly. Use some sort of state flag.
Never assume that the state is correct upon waking up. Check that state flag. This also means that the wait() method call will likely have to be in a loop.
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would advise you not to use wait(), notify(), or synchronized methods and statements. Instead use Locks and Conditions. These objects abstract away the thread communication mechanisms, and go some way to removing the problems you're describing.

See the Oracle documentation at http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/Condition.html
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!