• 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

"Synchronized" Doubt

 
Ranch Hand
Posts: 230
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Rather than saying it a doubt, I would like to say it, a clarification!

When one thread starts to execute a synchronized method, does it implicitly means that, IT HAS GOT THE LOCK ON THE OBJECT, whose synchronized method is invoked ?

Consider the following code :


===
Here the output is always
100
100
100
100
...
===

Is it because that, the thread t1 enters its synchronized run method, thus acquiring a lock on 's' object of Slave Class. While the main thread is not able to acquire the lock on the same object and thus not able to execute "s.setPrice(200);" ... Am I right?
[ October 30, 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
I have not got time at the moment to analyse this, but I can tell you that synchronized methods are using the lock associated with the class object of the class they are defined in. They are not using the lock of any instance of the class.

Ignore the above post please, I did not read the question slowly enough.
[ October 28, 2004: Message edited by: Barry Gaunt ]
 
Manikandan Jayaraman
Ranch Hand
Posts: 230
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Barry, can you again confirm me on your statement!

The lock on the "Class" object of this class holds good for STATIC SYNCHRONIZED methods. Right? I am just talking about SYNCHRONIZED METHODS WHICH BELONG TO AN INSTANCE.

Please confirm me on the same!
 
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
Sorry, I was in a rush to catch my train home from work. Yes what I wrote is for static synchronized methods. Sorry for the confusion.
 
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

When one thread starts to execute a synchronized method, does it implicitly means that, IT HAS GOT THE LOCK ON THE OBJECT, whose synchronized method is invoked ?



Yes. Until the first thread leaves the method no other thread can execute that same method or any other synchronized method of that class (for the same object). Your analysis of your program's behavior looks correct to me.
[ October 28, 2004: Message edited by: Barry Gaunt ]
 
Ranch Hand
Posts: 151
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Although this may be a slight tangent from your question, in the code you wrote for the class Master:


You should declare the boolean instance variable bContinue volatile to prevent the Java compiler from optimizing the code with a local copy.

 
Manikandan Jayaraman
Ranch Hand
Posts: 230
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Borderi Wrote:
You should declare the boolean instance variable bContinue volatile to prevent the Java compiler from optimizing the code with a local copy.

See ... It is a single object which both the threads are trying to access upon. So, the instance variable's value will be updated by either of the threads, depends on how you coded the program.

I dont find the need for a "volatile" qualifier for this variable because, as you can see the while loop checks for this boolean variable continuously and JVM will be again and again instructed to match the local value against the value in the master memory, which will be a performance overhead!
 
Joe Borderi
Ranch Hand
Posts: 151
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I dont find the need for a "volatile" qualifier for this variable because, as you can see the while loop checks for this boolean variable continuously and JVM will be again and again instructed to match the local value against the value in the master memory, which will be a performance overhead!

Although I agree that with the volatile keyword applied to bContinue will incur performance overhead, I still believe that the volatile is necessary.


Without the use of volatile, Java is free to optimze the loop in such a way that a local copy of [bContinue] is created. The use of volatile prevents this optimization, telling Java that [bContinue] may change in ways not directly apparent in the immediate code.

Schildt, Java 2: The Complete Reference (Fifth Edition), p. 292

 
reply
    Bookmark Topic Watch Topic
  • New Topic