• 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

Intrinsic Lock for static classes.

 
Ranch Hand
Posts: 226
Eclipse IDE Firefox Browser Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
By reading this tutorial: I have come across the following bit:

You might wonder what happens when a static synchronized method is invoked, since a static method is associated with a class, not an object. In this case, the thread acquires the intrinsic lock for the Class object associated with the class. Thus access to class's static fields is controlled by a lock that's distinct from the lock for any instance of the class.



I can't quite grasp the concept of the Class object associated wit the class.
Could anybody ,who is able to, explain it to me in other words? thanks a lot in advance?

Class object? So far I knew a class is a class an object is a class instance.

Thanks in advance.
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Nick Widelec wrote:I can't quite grasp the concept of the Class object associated wit the class.
Could anybody ,who is able to, explain it to me in other words? thanks a lot in advance?

Class object? So far I knew a class is a class an object is a class instance.



There is a class called java.lang.Class. A Class object (an instance of java.lang.Class) represents metadata about a given class, such as its name, the names and types of its member variables, the signatures of its methods, etc. It can be referred to statically like TheClassName.class (this is called a class literal, or it can be retrieved dynamically from a reference with the getClass() method. Class objects are used heavily in reflection.

As far as synchronization and locking is concerned (in fact as far as most things are concerned), it's just another object, and obtaining its lock has precisely the same effect as obtaining any other object's lock. What that quote is telling you is this:


 
Ranch Hand
Posts: 199
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jeff and Nick,

If I understand correctly the documentation referred by Nick when a thread executes an instance synchronized method all the instance is blocked to other threads.
Then no other instance method, synchronized or not, from the locked instance could be executed by another thread.

I realize that had always misunderstood that question :-(



 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Carles Gasques wrote:Hi Jeff and Nick,

If I understand correctly the documentation referred by Nick when a thread executes an instance synchronized method all the instance is blocked to other threads.
Then no other instance method, synchronized or not, from the locked instance could be executed by another thread.



No, that's not how it works.

When I enter a sync block or method, I obtain a particular object's lock (see my sample code above to know which object). All that does is prevent other threads from obtaining that same lock. Any thread can still enter any sync block that uses a different lock that's not already held, and any thread can still enter any unsynchronized block or method.
 
Carles Gasques
Ranch Hand
Posts: 199
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jeff,

You say that a thread only holds the lock for an instance when trying to use a synchronized method,
then no other thread could use any synchronized method of the instance (get the instance lock).

No synchronized methods are always 'freely available' for any thread.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Carles Gasques wrote:Hi Jeff,

You say that a thread only holds the lock for an instance when trying to use a synchronized method,



Or a synchronized block.

then no other thread could use any synchronized method of the instance (get the instance lock).



Correct. No other thread can obtain that lock--that is no thread can enter a sync method or block that syncs on that same instance as long as some thread holds that lock.

No synchronized methods are always 'freely available' for any thread.



If you mean that unsynchronized methods are always freely available, then, yes, you're correct.

If that's not what you mean, can you clarify what you're trying to say?
 
Carles Gasques
Ranch Hand
Posts: 199
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jeff,

Thanks for the explanation.

And yes, I was trying to say "unsynchronized" in my mumbling English (no synchronized) :-)
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You're welcome!
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic