• 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

q on multithread interactive

 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Thank you!

[ December 10, 2004: Message edited by: Jonathan Schwartz ]

(shortened comment lines and fixed indententation)
[ December 10, 2004: Message edited by: Barry Gaunt ]
 
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just because you have done b.start() does not mean that the run method will run immediately. The Java Virtual Machine will decide when to run that thread, and it may decide to let the main thread continue and grab the lock. You can give a hint to the JVM that b should run by setting a higher priority for thread b before you start it (no guarantee though), or you could make main yield the processor (again no guarantee), or you could make main sleep (again no guarantee, but at least a possibility), or you could make it join thread b.

Also there is the possibility that b does finish before the main thread waits, then the notify would be lost, and main would wait for ever.


What is the output you get?
[ December 11, 2004: Message edited by: Barry Gaunt ]
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Another scenario is:

The main thread creates and starts thread b. Thread b does not run yet.
The main thread continues, grabs the lock on b.
The main thread waits, thereby releasing the lock on b. The main thread is rescheduled.
Thread b now runs and grabs the lock.
Thread b's run completes and it send the notify. Thread b then releases the lock.
The main thread wakes up because of the notify and regains the lock.
The main thread releases the lock immediately, and then prints the total calculated by b's run method.
 
tao wu
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you.I have understand part of them.
Is you mean
The second case you list is we wanted usually.
The first case (use sleep or join...)the result is wrong,they can't get the "totol=",is that means in the case that notify exec before wait will be dangerous,this programme would be frozen for ever?
If this case will happen possibly ,how to prevent it?
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jonathan Schwartz:
Thank you.I have understand part of them.
Is you mean
The second case you list is we wanted usually.
The first case (use sleep or join...)the result is wrong,they can't get the "totol=",is that means in the case that notify exec before wait will be dangerous,this programme would be frozen for ever?
If this case will happen possibly ,how to prevent it?



Two rules to live by:

- Never perform a wait() until you have to. This means after you grab the synchronized lock, check to see if the item is not available (via a flag) first. The other side should set the flag, again in synchronized code, prior to calling notify().

- Never assume the condition is met upon return from wait(). After you return from wait(), check to see if the flag is still set, grab what you need to continue, clear the flag, and continue. Otherwise, call wait() again.

Henry
 
Henry Wong
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
BTW, here are the changes to your code to conform to those two rules mentioned.



Hope this helps,
Henry
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"Jonathan Schwartz", Henry has given you a very good (and standard) solution to your problem. If you really want to use threads a lot, get the latest (3rd edition) of his book "Java Threads".
 
tao wu
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for Henry and Barry's help.i understand.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic