• Post Reply Bookmark Topic Watch Topic
  • New Topic

parameter to sync block

 
william kane
Ranch Hand
Posts: 260
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is the use of
class TestSync{
private static Object lock=new Object();
methodTestSync(){

synchronized(lock){
/////......../////
/////.........////
}
}
when compared to
methodTestSync(){

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

In both the cases i am trying to ensure that the thread that accesses the synchronized block will have to acquire the lock for the TestSync instance.
My question is ,what is the advantage i get by using the "lock" object(As recommeded in some articles) as a parameter to the sync block as compared to using "this" as the parameter to sync block.
 
V Chauhan
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Since your method methodTestSync is not static, in the second example, the lock will be with respect to the object on which you are invoking the method. But with the first example the lock will be with respect to the private static object.
So if you have n instances of the class TestSync, all of them can concurrently execute the method TestSync with the second example. This is not the same with the first example.
 
william kane
Ranch Hand
Posts: 260
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by basudev agrawal:
This is not the same with the first example.

How does that work?When a thread enters the sync block of the first method it acquires the lock for the non static sync methods of current instance of TestSync class and the non static sync methods of lock instance of Object class.How does that prevent the other the sync block of instances of TestSync from being accessed by other threads???
Please clarify....
 
V Chauhan
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The difference between the two methods lies in the object on which you are trying to acquire the lock.
If you have n instances of TestSync class, with the second example, they will be able to execute the method methodTestSync concurrently, since the lock is acquired on the respective objects.
But with the first example, you are always acquiring the lock on one object i.e., the static member "lock". So all the instances will try to acquire the lock on this object and only one will succeed. The others will have to wait.
Hope it helps..
 
william kane
Ranch Hand
Posts: 260
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by basudev agrawal:

But with the first example, you are always acquiring the lock on one object i.e., the static member "lock". So all the instances will try to acquire the lock on this object and only one will succeed. The others will have to wait.
Hope it helps..

But object class (and therefore its instance "lock")doesnot have any non static sync methods that can get locked because of the the thread enters the sync block of first method.What is the significance of a object lock i my object doesnot have sync methods???
 
Timmy Marks
Ranch Hand
Posts: 226
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let us suppose that you have 2 threads (T1 and T2) and 2 instances of TestSync (a and b). T1 wants to call a.methodTestSync() and T2 wants to call b.methodTestSync().
first version {synchronized on the static Object }
since it is static, there is only one instance of it, so if T1 goes into
the block, T2 has to wait for the lock.

second version {synchronized on }
when T1 tries to execute a.methodTestSync(), it gets the lock and goes into the synchronized block.
along comes T2 and calls b.methodTestSync() and can also go into the block
even if T1 is still in the block. That is the difference in the two methods.
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"this" refers to the object that it is being called from within, and has NOTHING to do with the thread?
I think you may be mixing up threads and objects a bit in your mind.
Neither of your examples is better than the other, they simply do different things. The first example has only 1 lock, the second example will have 1 lock for each instance of the class TestSync. In fact, the instance is the lock object in the 2nd example.
 
Timmy Marks
Ranch Hand
Posts: 226
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"this" refers to the object that it is being called from within, and has NOTHING to do with the thread?

Exactly. If you call the method a.testSync(), "this" refers to a. If 47 different threads try to call a.testSync(), only one at a time will be allowed in (in either version of the method).
The difference comes when you have two different instances of this class. There are then two different possibilities for "this", but only one "lock" because it is static, so a.testSync() and b.testSync() could be running concurrently in the second version, but not in the first.
I think you may be mixing up threads and objects a bit in your mind.

Not at all. Threads and objects are mixed up together. Synchronization is there to protect data (stored in objects) from becoming corrupted when accessed from different threads.
Neither of your examples is better than the other, they simply do different things. The first example has only 1 lock, the second example will have 1 lock for each instance of the class TestSync. In fact, the instance is the lock object in the 2nd example.

I never said either one was better The two lines of code serve different purposes. The first one would be used to protect class data or to ensure that only one instance of testSync could execute at a time, and the second would be used to make sure that only one consumer at a time could access instance data for a certain instance.
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with everything you said Timmy
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!