• 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
  • Tim Cooke
  • Devaka Cooray
  • Ron McLeod
  • Jeanne Boyarsky
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
  • Tim Holloway
Bartenders:
  • Martijn Verburg
  • Frits Walraven
  • Himai Minh

Threads k&B page 720

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

I need your help, I don't understand the way this code works.
I thought that after writting b.start(); the code within the run() method
will be excuted.But it's excuted only later in synchronized.why ?






This is the output :

total value before the start method :0
total value after the start method :0
Waiting for b to compl�te ..
***********In the run method****************
After the wait
Total is : 4950
***************End of the run method******************
total value in synchronized method :4950

I have looked for in the old posts and i find one about this problem but the answer wasn't clear. Thank you for your help.

Armel
 
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Threading behavior is JVM dependent and underlying OS.In this program, by seeing output it seems like Service thread main keeps running and gets the lock on Object B then after the flow hits the wait() method where it releases the lock and goes back to runnable state where it waits until somebody notifies it(in this case the Thread B does this work). the Thread which has began by invoking .START() gets it, completes the loop and hits the notify(), then after main gets it, and completes the following statements.

- the point is , b.start() does not guarantee that it will make thread running

- chintan
 
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 Armel Moukoss:
...I thought that after writting b.start(); the code within the run() method will be excuted. But it's excuted only later in synchronized. why? ...


Once start() is called, it's up to the (platform-dependent) thread scheduler to decide when the new thread is given a chance to run. It's unlikely that the new thread's run method will be executed immediately after start is called.

If you run this program repeatedly, you will likely see different results. In this particular example, the output indicates that after calling start, the main thread continues running. It executes the println, then enters the synchronized block and obtains b's instance lock, then executes another println before calling wait.

Important: Note that wait() is an instance method defined in Object (not Thread) that causes the current thread to wait. In this case, the Thread instance b is used to invoke the instance method wait(), but it's the current thread -- not b -- that waits.

Waiting releases the main thread's hold on b's object lock. This allows b's run method to execute and obtain the object lock in its own synchronized block. After it's completed summing 1 through 99, it calls notify and leaves the synchronized block, releasing the lock.

notify() allows the original thread (main) to stop waiting and resume its execution -- but again, it's up to the thread scheduler to decide exactly when this happens. In this particular example, the main thread obtained b's lock again and resumed execution. After the main thread finished, the thread scheduler allowed b to execute its println statements.

I ran this example a few times (on a Windows machine), and occasionally saw b complete before the main thread was given a chance to resume. This illustrates how (platform-dependent) thread scheduling is unpredictable.
 
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you read carefully the description of this code in book you will get idea.

When you start b, it doesn't mean, that thread will start immediately. In class ThreadA main method is also a thread. So it is possible that main can starts before thread b. So that they use synchronized code to take a lock of b object & put the current thread(main thread) in wait. At line 9 b.wait release lock, so now code executes run method. After notify, wait thread wakes up & prints Total.
I think you will get now.
 
Ranch Hand
Posts: 377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by chintan ramavat:
after the flow hits the wait() method where it releases the lock and goes back to runnable state where it waits until somebody notifies it


Only for correctness. The thread goes into the waiting state.
 
Armel Moukoss
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thank you guys for your help !!!

Armel
 
Armel Moukoss
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have another question if i delete the notify() method in class ThreadB i have the same result. I thought that without notify in class ThreadB, the class ThreadA will still wait. ThreadA complete his synchronized code without any problems.

Do you have any answer for this question ? Thank you.

Armel
 
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
Interestingly, I just ran this several times on a Mac, and it's deadlocked every time with the following output...

As demonstrated in a previous example, the Mac thread scheduler seems much more eager to share CPU time among threads. As the output above indicates, b's run method begins executing immediately after start is called (as the original poster expected).

In other words, as soon as the other thread is ready to run, the Mac thread scheduler gives it CPU time instead of continuing on with the current thread. This illustrates a serious flaw in the above code, which seems to assume that the thread scheduler will be lazy, allowing the main thread into its synchronized block to call wait() before b's run method enters its synchronized block and calls notify().
 
Manfred Klug
Ranch Hand
Posts: 377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Armel Moukoss:
I have another question if i delete the notify() method in class ThreadB i have the same result. I thought that without notify in class ThreadB, the class ThreadA will still wait. ThreadA complete his synchronized code without any problems.

Do you have any answer for this question ? Thank you.

Armel

At least with the JRE from Sun, notify() is used internally. Whenever a thread dies, it does a notifyAll() on itself. This is the reason why you don't see a deadlock.
 
Armel Moukoss
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you Manfred Klug for your help.

Armel
 
Uh oh, we're definitely being carded. Here, show him this tiny ad:
the value of filler advertising in 2021
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic