• 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

Wait and Notify from KS&BB

 
Ranch Hand
Posts: 83
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In the KS and BB book pages 720 and 721. I found this piece of code:

1. class ThreadA {
2. public static void main(String [] args) {
3. ThreadB b = new ThreadB();
4. b.start();
5.
6. synchronized(b) {
7. try {
8. System.out.println("Waiting for b to complete...");
9. b.wait();
10. } catch (InterruptedException e) {}
11. System.out.println("Total is: " + b.total);
12. }
13. }
14. }
15.
16. class ThreadB extends Thread {
17. int total;
18.
19. public void run() {
20. synchronized(this) {
21. for(int i=0;i<100;i++) {
22. total += i;
23. }
24. notify();
25. }
26. }
27. }

My question is: What happens if after line 4, the thread scheduler runs thread b's run method from start to finish (including the notify). Next switches execution to the main method. The method would get to line 9, then wait for a notify (which has already ran). Would this make it wait forever? I sure hope i did a good job of explaining my question. Thanks for your help ranchers!

Yeuker
 
Sheriff
Posts: 11343
Mac Safari Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Cory Max:
... Would this make it wait forever? ...


Indeed, that's exactly what happens when I run this code. (I need to press Ctrl+C to get the command prompt back.)

I'm using a Mac, which I've noticed to be very quick to switch between threads. So when b.start() is called, b is usually given a chance to run before the next line in the main thread executes. I expect that on a Windows machine, the main thread would usually continue to the next line and start waiting before b is given a chance to run.

You could force this scenario to happen by inserting a call to sleep after b.start() is called. This would give b a chance to finish running and call notify before wait is called in the main thread. (See code below.)

Note that you can also specify a maximum amount of time to wait, so that it will not wait forever. In the code below, I've inserted a 3-second timeout so that the program does not freeze up.
 
marc weber
Sheriff
Posts: 11343
Mac Safari Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by marc weber:
...I'm using a Mac, which I've noticed to be very quick to switch between threads. So when b.start() is called, b is usually given a chance to run before the next line in the main thread executes. I expect that on a Windows machine, the main thread would usually continue to the next line and start waiting before b is given a chance to run...


I just tested this on a Windows machine, and it's as I expected. Roughly 80% of the time, after calling b.start(), the main thread continues to the next line before b is given a chance to run (unless the added code to call sleep is used).
[ December 10, 2007: Message edited by: marc weber ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic