Win a copy of Head First Android this week in the Android forum!
  • 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:
  • Tim Cooke
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Jesse Silverman
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Al Hobbs
  • salvin francis

Threading synchronization

 
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

Please check the following code:



Despite of the method callMe being synchronized, when I run the program, I get the following output:



I would expect one of the threads to enter the callMe() method and stall it, so that the second thread cannot enter it at all! Can someone please help me understand the output? Also, if there is something wrong here, how do I correct it so as to allow only one thread to enter the method?

Thanks,
NP
 
Sheriff
Posts: 22508
122
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Both MyThread instances synchronize on itself - their synchronization is separated.

The following will work as you expect:
This is because the same MyThread instance is used (as a Runnable) in two different threads.
 
Natalie Ap
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Rob,

I tried doing that. But my output is as follows:

FirstThread
FirstThread
FirstThread
FirstThread
FirstThread
FirstThread
FirstThread
SecondThread
SecondThread
SecondThread
SecondThread
SecondThread
SecondThread

Why does the Second thread enter the method at all when it is a synchronized method and when there is an infinite loop within it!

NP


Rob Prime wrote:Both MyThread instances synchronize on itself - their synchronization is separated.

The following will work as you expect:
This is because the same MyThread instance is used (as a Runnable) in two different threads.

 
Rob Spoor
Sheriff
Posts: 22508
122
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That's odd. I tried it myself just now, and after about 12 seconds I aborted without a single "SecondThread" - after almost 1 million "FirstThread"s.
 
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
it might be something with the thread schedular
 
Ranch Hand
Posts: 282
Eclipse IDE PHP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Rob's code worked for me.

Thread scheduling shouldn't have anything to do with it, since locking is involved.
 
Cody Long
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
there are never any gaurentees when it comes to the schedular
 
Rob Spoor
Sheriff
Posts: 22508
122
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Correct; you can't guarantee which of the threads fires first. However, the synchronization should enforce you either get only "FirstThread"s or only "SecondThread"s - not both.
 
Cody Long
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Very true but your output also depends on the JVM.
 
author
Posts: 23909
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

Cody Long wrote:there are never any gaurentees when it comes to the schedular



Yes, but there are limits on what can actually happen. It doesn't matter how bad the scheduler is... schedulling a thread that doesn't own the lock to execute code that requires the lock, doesn't make the thread execute the code -- a thread that is in a blocked state will just release its timeslice.

Very true but your output also depends on the JVM.



Again true. But that doesn't mean that there is a JVM out there that doesn't honor synchronization locks -- at least one that has been certified as a valid JVM.

Henry
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic