• 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

Object Locking And Class Locking

 
Ranch Hand
Posts: 40
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


I am expecting this code to give an erratic output as I acquire a lock at the class level instead of the shared object. However, to my utter surprise this is behaving as if the lock has been acquired on the shared object itself and doesn't output anything erratic.

My understanding for OBJECT LOCK is that implementation should have gone like:



My understanding for CLASS LOCK is that implementation should have gone like:



and in the run method...



Is there any gap in my understanding or am I missing on any concept. I would really appreciate if somebody can help.
 
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

In one case, all your threads are using the same shared instance as the synchronization lock. The Shared object instantiated in the main() method.

In the other case, all your threads are using the same shared instance as the synchronization lock. The Class object for the TestTh class.

Henry
 
Shouvik Bhattacharya
Ranch Hand
Posts: 40
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok....so then it essentially means that when multiple instances of a class get instantiated then there are multiple locks in the picture i.e. one lock per instance but since there exists precisely one and only one Class Lock like in the example stated above, which also happens to get shared amongst multiple threads, so if a thread enters a synchronized block acquiring a lock on TestTh.class then other threads are obligated to wait until the currently running thread finishes executing that block irrespective of the fact whether a method is a static or instance one like in the above case.
 
Shouvik Bhattacharya
Ranch Hand
Posts: 40
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Guys...would be great if somebody can clarify the thing on my post above.....thanks
 
Marshal
Posts: 28177
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, you seem to think that a "class level" lock is somehow different than the regular locks you get by synchronizing on an object. But it isn't any different. Line 4 of your sample code:



is synchronizing on an object too, it's synchronizing on an object of type Class, namely the TestTh Class object. Likewise



is synchronizing on an object, it's synchronizing on an object of type Shared.

So in all cases the code synchronizes on an object, because that's all you can synchronize on. The difference, as you've already noticed, is that in the first example everything synchronizes on the same object whereas in the second example synchronization on different objects may be taking place. But there's nothing else different, and again there's nothing special about synchronizing on a Class object.

 
Shouvik Bhattacharya
Ranch Hand
Posts: 40
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok....thanks mate ..but I think even in the second example things are synchronizing on the same object.
 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Shouvik Bhattacharya wrote:Ok....thanks mate ..but I think even in the second example things are synchronizing on the same object.


They are. And in the second case it's absolutely certain that they will all be synchronising on the same object, because there IS only one: TestTh.class.

In your first example, you could create as many Shared objects as you like, and run your Threads on any one of them, but you don't. You only create one object - so the effect is the same as your second example.

HIH

Winston
 
Shouvik Bhattacharya
Ranch Hand
Posts: 40
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey thanks Winston...really learnt some valuable stuff here as far as the lock part is concerned. I was kinda under the illusion that static is to Class Lock and instance is to Object Lock, well things can be taken that way but now I feel that if the context demands thread safety of your instance then its the instance under consideration upon which appropriate synchronization efforts should be carried out in order to protect instance related state and on similar grounds when talking about Class properties or in other words the static guys the context demands synchronization efforts on the Class to be made. In short we can say that there is a lock available its up to the developer to make sure that he understands the contexts needs and codes accordingly. Hopefully I have understood.
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Shouvik Bhattacharya wrote:I was kinda under the illusion that static is to Class Lock and instance is to Object Lock...


Which IS true if you put synchronized on a method. But you're not; you're specifying the object to lock.

well things can be taken that way but now I feel that if the context demands thread safety of your instance then its the instance under consideration upon which appropriate synchronization efforts should be carried out in order to protect instance related state and on similar grounds when talking about Class properties or in other words the static guys the context demands synchronization efforts on the Class to be made. In short we can say that there is a lock available its up to the developer to make sure that he understands the contexts needs and codes accordingly. Hopefully I have understood.


Sounds about right, but you don't have to use:
  synchronized(Object)
in either case.

Winston
 
Shouvik Bhattacharya
Ranch Hand
Posts: 40
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yup... I understand your point....but the following thing in quote was done deliberately on my part just have my appropriate understanding in place

Winston Gutkowski wrote:
Sounds about right, but you don't have to use:
  synchronized(Object)
in either case.



synchronized method would have worked as well.
 
Marshal
Posts: 79151
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Removing from beginning forum as question is too difficult
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic