• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

synchronized block

 
Simon Joseph Aquilina
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello, I have a quick question on synchronized block. If I have a common object "c" then shouldn't the following code block any access to object "c" until all code in the block is ready?



This seems not to be the case for one of the examples I wrote. Basically I created two objects; JobA and JobB. JobA calls longCount from a synchronized block as above. JobB does not call longCount from a synchronized block. I start JobA and JobB as follows:



The result is as follows:



As one can see, because JobB couldn't care less about what JobA is doing (i.e. - did not use a synchronized block), ultimately it undermines what JobA is doing. If JobB had wrapped its calls to longCount within a synchronized block then first JobA would have finished its count and then JobB would have started.



So my question is the following;

Am I right to assume that synchronized block does not guarantee that the code currently being executed cannot be executed from another thread, while a synchronized method DOES give such guarantee?

What is the use to synchronize on the Common object?

 
Stefano Carniel
Greenhorn
Posts: 11
C++ Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm quite new to java, but I'm studying synchronization and multithread issues. I try to answer, but wait for someone else too.

So, you have two jobs accessing the same object. Both of them must use synchronized blocks to access the object, otherwise synchronization could not be guaranteed.
In this particulare case, the best practice should be declaring as synchronized the method longCount. In this way you have not to take care of all other task accessing the object.
Hope it's clear (despite my broken english :P)
 
Chan Ag
Rancher
Posts: 1089
14
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If I have a common object "c" then shouldn't the following code block any access to object "c" until all code in the block is ready?

Am I right to assume that synchronized block does not guarantee that the code currently being executed cannot be executed from another thread, while a synchronized method DOES give such guarantee?

What is the use to synchronize on the Common object?


We must understand one thing here. Synchronization is a joint responsibility of the class/design of the system. We may make a particular block synchronized and that may be enough to guard a critical resource from concurrent reads/writes. But sometimes it may not be so. Sometimes synchronization may not be required ( very unlikely, but not impossible ) at all if the semantics of the class are such that there is no race condition.

Synchronized blocks just create a guarded section. They do not guard the resource. But if you are accessing the resource that you want to protect, outside the guarded section, well it's not protected.
For guarding the resource, you may sometimes need to create more than one critical section or you may need to employ additional means to safeguard your critical resource from concurrent reads/writes.

You might have made a particular block synchronized cause you thought threads are going to concurrently access the protected resource in that particular block. But how about the rest of your class?
How about the other methods? How about the whole series of method invocation involved here?

In the absence of additional but required synchronization, nothing prevents me from accessing the common resource from another non-synchronized method/blocks. And that may be just one of the things.
Chan.


 
Simon Joseph Aquilina
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Chan Ag wrote:Synchronized blocks just create a guarded section. They do not guard the resource. But if you are accessing the resource that you want to protect, outside the guarded section, well it's not protected.


Exactly, that is what I observed after some experiments ...
Using synchronized blocks will not guard the resource, the resource must be developed to guard itself (using synchronized blocks or methods).

Thanks


 
Luan Cestari
Ranch Hand
Posts: 172
C++ Redhat Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Chan explained everything. In summary: The block synchronization will not guarantee that you will access another non-thread-safe resource. So, if you use correctly the block synchronization you will have the same behavior of using method synchronization. =)
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic