• Post Reply Bookmark Topic Watch Topic
  • New Topic

Synchronized block functionality  RSS feed

 
VipulKumar Jain
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Scenario : I'm running 2 threads in parallel (main thread & another thread). Both are accessing a common object of class Destination (d).
Both threads will try to update this common object during runtime.

Case1 : The code specific to updating to object d, is into synchronized block for both of the threads, as provided below:





Output gets printed correctly, I.e. only one thread is accessing the synchronized block at a time.



Case2 : If only one thread has written that code in the synchronized block, then (remove synchronized block from the main method):





Now, in this case both threads are accessing the common object and updating its value also. So that means that even the thread executing the synchronized code will not put lock on the object d. Any thread without synchronized method/block can have access to its resources.

Can anyone tell me the logic behind this code execution?
 
Joanne Neal
Rancher
Posts: 3742
16
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
VipulKumar Jain wrote:So that means that even the thread executing the synchronized code will not put lock on the object d

Yes it will, but as no other thread ever tries to gain the lock, it will have no effect on the code execution.

VipulKumar Jain wrote:Any thread without synchronized method/block can have access to its resources.

Correct.

VipulKumar Jain wrote:Can anyone tell me the logic behind this code execution?

I'm not sure I understand the question. The output of the code is unpredictable because there is no synchronisation between the two threads.
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Joanne Neal wrote:
VipulKumar Jain wrote:Can anyone tell me the logic behind this code execution?

I'm not sure I understand the question. The output of the code is unpredictable because there is no synchronisation between the two threads.


I think that the OP may be under the impression that owning the synchronization lock, actually locks some sort of functionality related to code or variables. It doesn't. Owning the synchronization lock just prevents other threads from owning the same synchronization lock. And threads have to work cooperatively to synchronize with each other.

Henry
 
VipulKumar Jain
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry Wong wrote:
Joanne Neal wrote:
VipulKumar Jain wrote:Can anyone tell me the logic behind this code execution?

I'm not sure I understand the question. The output of the code is unpredictable because there is no synchronisation between the two threads.


I think that the OP may be under the impression that owning the synchronization lock, actually locks some sort of functionality related to code or variables. It doesn't. Owning the synchronization lock just prevents other threads from owning the same synchronization lock. And threads have to work cooperatively to synchronize with each other.

Henry


Okay, now I got the ground of the synchronized lock. I was under the impression that, if one thread has put synchronized lock over the instance of the object then no other thread can access it (during locked period).
Thanks all for providing valuable comments over the post.
 
Venkateswara Myla
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In synchronized block we are getting lock on a particular object (in this case Destination object), any synchronized method in that object is not accessible by other threads/object if a thread already holds the lock on that object.
The remaining methods which are not synchronized can be accessed by other threads/object even if a thread already holds the lock on that object.

In this case we are not synchronizing the data access in the Destination class, we need to move this synchronization logic to the Destination object.
 
Campbell Ritchie
Marshal
Posts: 56584
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!