Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Thread locking  RSS feed

 
Rohan Pujari
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator




When the thread1 finishes executing the method of nt object then it has dropped the lock for the nt object. but still it continues to execute and only after thread1 finishes does thread2 start executing.

now only one thread enters a synchronized block but in the above case the lock that the thread acquire is of a different object so in general does it imply that

Even if in a synchronized block when a thread acquires a lock on a third party object and finishes executing a synchronized method of that object(effectively dropping the lock), another thread cannot enter the synchronized block till the first thread leaves the block?
 
Henry Wong
author
Sheriff
Posts: 23283
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Even if in a synchronized block when a thread acquires a lock on a third party object and finishes executing a synchronized method of that object(effectively dropping the lock), another thread cannot enter the synchronized block till the first thread leaves the block?


You do know that this example is more complex that it needs to be? It took me a while to realize that the private thread object was not started!

Anyway, what you are seeing is just nested locking. Basically, if you own a lock, and you try to grab the same lock again, it will be allowed. Otherwise, you'll deadlock with yourself. Only when thread1 completely releases the lock (either by leaving the original sync block, or by calling wait()), will other thread be able to acquire the lock.

Henry
 
Rohan Pujari
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
so does it mean that private object nt does not have lock associated with it?
 
Henry Wong
author
Sheriff
Posts: 23283
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Rohan Pujari:
so does it mean that private object nt does not have lock associated with it?


All objects have a lock that can be acquired -- regardless of whether is it is public or private.

Now sure how you drew this conclusion, but let me elaborate what is happening...

When thread1 syncrhonized on nt, it acquired the lock, when thread1 called the sync method, it acquired it again. It now owns it twice. When thread1 returned from the sync method, it released it, it now just own it once. And when thread1 leaves the sync block, it finally completely released the lock. Now... thread2 can acquire the lock.

Henry
 
Rohan Pujari
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yep i got it. I made some changes to the original program i made the nt object as static and also ran a 3rd thread giving it nt as the runnable target. The output is exactly what you have explained. First thread1 executes and the moment it leaves the synchronized block thread2 enters and starts running and finally thread3 enters only when 2 has finished or has exited out of the block.

Whew threads can get really confusing at times

Thanks Henry
 
Chandra Bhatt
Ranch Hand
Posts: 1710
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Rohan,


Even if in a synchronized block when a thread acquires a lock on a third party object and finishes executing a synchronized method of that object(effectively dropping the lock), another thread cannot enter the synchronized block till the first thread leaves the block?


It seems to me, you are drawing some conclusion in the suspicious
way. "third party" means?

SyncTest Has-A NewThread so object of NewThread is soul part of
the SyncTest. You are creating only one object of SyncTest as "PayLoad"
and two launchers (threads) are there. In one method you have lock on
the nt (NewThread) and because there is only one SyncTest object, both
threads will behave gently, working one after one. What monitor you are using is member of the instance st(SyncTest object created in the main()).

So therfore after and only after one thread finishes it job or say comes out
of the critical section, leaves the monitor, then another thread can enter
that section.

With Regards,
cmbhatt
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!