Win a copy of Rust Web Development this week in the Other Languages 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
  • Ron McLeod
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Junilu Lacar
  • Rob Spoor
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Jesse Silverman
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Frits Walraven

Nested synchronized

 
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,
I am a new reader in this forum. Can any one please justify the use nested synchronized on the same object. i.e

synchronized(this)
{
synchronized(this){}
}.

As I already got the lock in the first "this", what is the utility for the second "this"?I know synchronized(a){ synchronized(b){}} is required when I need both lock for object "a" and "b".

 
Ranch Hand
Posts: 298
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Basically Nested Synchronization implies for two different objects, i mean outer synchronization for a different object and inner one for a different one. This should be avoided as deadlock may occur.

Having nested Synchronization on the same object will give the same result as being not a nested one. Its just the same. Why would u like to do it? It may just increase performance overhead.
 
Ranch Hand
Posts: 443
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A thread can lock an object many times. Everytime a thread locks an object, JVM increments the lock count of that object. But only the thread that owns the lock can do this. Only when the lock count is zero is when you consider the object lock to be released. Therefore, the number of times the thread locks an object must be the same no. of times it must unlock it.
 
Sonal Ray
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Animesh and Alton.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic