Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Class Lock and Object Lock  RSS feed

 
Muralidhar Mandapati
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dear All,

I am newbie to this threading concepts. Can someone explain how does the class lock differs in the object Lock.
All i knew is the if the static method in a class is synchronised then it acquires the class lock while the instance methods which are synchronised acquires object locks.

I assume that the class files which we do get as the result of the compilation of the jave files are class objects are used for the creation of instance object. Does this class lock implies that Other thread which are trying to create instances of this class would not be permitted until lock is acquired.

Please do correct me.. I am not aware of this ..

Thanks in advance,
Murali
[ November 26, 2004: Message edited by: Muralidhar Mandapati ]
 
Henry Wong
author
Sheriff
Posts: 22848
119
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Take this code...

SomeObject.synchronizedMethod();

If the method is not static, the object used as the lock is the "SomeObject" object. If the method is static, the object used as the lock is the "SomeObject.getClass()" object.

Since there is one Class object representing all of the classes of that type, it is perfect for static methods.

Henry
 
Muralidhar Mandapati
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Henry,
But i was wondering that does all the objects of the same class ( example different instances of the same classes ) return the same class object when we say
SomeObject.getClass();

Thanks and Regards
Murali
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, in a simple world they should all return the same object of a type extending Class. Things get more complex when you have multiple classloaders; each classloader will make a new instance.

Imagine the classloader reading a .class file off disk. It's getting a lot of information from the file and has to store it somewhere. In some object. Of some type. But multiple classloaders don't share, so they each make their own instances of the class data.

Man, no matter how many times I try to find a way to explian this it sounds like doubletalk ... Who's on first? Hope it made some sense.
 
Henry Wong
author
Sheriff
Posts: 22848
119
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Man, no matter how many times I try to find a way to explian this it sounds like doubletalk ...


When I am asked about this, particulary when asked in person... I sometimes add a recommendation...

I recommend avoiding it. I recommend creating an external object for explicit synchronization, instead of trying to remember which methods are static, which are not, and whether or not the method is actually a method of the class, or superclass, etc.

After all, it is better to build a locking mechanism that works for your algorithm, than to modify your algorithm to fit into a default mechanism that is sometimes confusing.

Henry
[ November 26, 2004: Message edited by: Henry Wong ]
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Henry Wong:


When I am asked about this, particulary when asked in person... I sometimes add a recommendation...

I recommend avoiding it. I recommend creating an external object for explicit synchronization, instead of trying to remember which methods are static, which are not, and whether or not the method is actually a method of the class, or superclass, etc.

After all, it is better to build a locking mechanism that works for your algorithm, than to modify your algorithm to fit into a default mechanism that is sometimes confusing.

Henry

[ November 26, 2004: Message edited by: Henry Wong ]



Here here!

I fully endorse always using objects created specifically for locking purposes as your lock objects, and I fully encourage you to never use the keyword synchronized on the method level!

To the point of the original question, the class lock is an object lock. Each class that is loaded has an object in memory that represents the class itself as opposed to an instance of the class. That object is returned when you say this.getClass(); That is the object which is locked on during static method locks. The substitute for this which I endorse is instead using a static reference to a variable as your lock object.


There is a difference between the Thread class, and a thread. The Thread class creates a thread, but they are not at all the same thing.

Also note that "lock" is sort of a misnomer because it does not prevent anything. You have to respect it. How you use it determines the scope of its effect.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!