aspose file tools*
The moose likes Threads and Synchronization and the fly likes Synchronized Block Of Code Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Synchronized Block Of Code" Watch "Synchronized Block Of Code" New topic
Author

Synchronized Block Of Code

Craig Oliver
Greenhorn

Joined: Aug 25, 2003
Posts: 21
I have a reasonable understanding of synchronized methods (I think), but bit confused about synchronized blocks.

I am confident of following statement, but please advise if incorrect.

"When a synchronized instance method is being executed, no other thread can execute that method or any other synchronized methods of that object. Another thread can execute un-synchronized methods of that object. Another thread can execute that method on another instance."

Assume object o1 contains no synchronized methods, but wish to synchronize access to some code. When synchronize using synchronize(o1){o1.meth()} and calling o1 methods what is the effect of this? Does this lock out other threads from accessing any methods of o1? In this case is it true that there is no concept of unsynchronized code that other threads can execute? Is it true that the whole point of synchronizing an object through this method is that you cannot modify source code to synchronize some methods and not others, so just have to synchronize the lot?
Jose Botella
Ranch Hand

Joined: Jul 03, 2001
Posts: 2120
Welcome to the Ranch Craig!

The quoted sentence is perfectly accurate, except that another thread could execute a static synchronized method because the locks are different. A static method uses the lock of its Class object.


When synchronize using synchronize(o1){o1.meth()} and calling o1 methods what is the effect of this? Does this lock out other threads from accessing any methods of o1?


If o1 has not used synchronized in the declaration of its instance methods, the code above won't prevent other threads from executing such methods. However it will prevent any other thread trying to call any method from within a block synchronized on o1: synchronized(o1) { /*not executed untill lock is free*/ }


Is it true that the whole point of synchronizing an object through this method is that you cannot modify source code to synchronize some methods and not others, so just have to synchronize the lot?


It is true that one of the reasons to use the synchronization blocks could be not being able to modify the source code of its class. Another is that you do not want to synchronize the whole method but only a portion of it.
In the former case it is intended that every access needing synchronization is writen within a synchronized block. Thus, it might not synchronize anything is that advice is not followed. But I wouldn't say that a synchronized block synchronizes the whole object. It would synchronize only the code writen within the block.
[ May 23, 2004: Message edited by: Jose Botella ]

SCJP2. Please Indent your code using UBB Code
Craig Oliver
Greenhorn

Joined: Aug 25, 2003
Posts: 21
Hi Jose. Thanks for your reply.

Looks like I had block synchronization all wrong. Thats why Java Ranch community is so good; allows clarification of concepts. Can we keep working with synchronized blocks? See if I have following correct

Case one - Synchronize Current Object
In an instance method that is not synchronized, may just synchronize part of code by using synchronize on block of code within method and synchronize on current object
eg
method1
{
code
synchronize(this)
{
synchronized code
}
more code
} // end method

In above case more than one thread can execute method1 on same object but only one thread will execute synchronized code at a time.

Case Two - Synchronize Another Object
This is case I am really struggling with.
eg
method1
{
code
synchronize(someOtherObject)
{
someOtherObject.methodA;
}
more code
}

Does this mean no other thread can execute someOtherObject.methodA at time when a thread is within synchronized block?

Is there anyway, that you can externally synchronize a method that is not synchronized and you cannot alter?
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24166
    
  30

Take your original description of synchronized methods and change "method" to "method or block" and you'll have a good starting point. A block that is synchronized on an object acts just like a synchronized method of that object. If class A has synchronized methods x(), y(), and z(), and if some other class B includes a block like



then while this block is executing, no code can call x, y, or z on that object a.


[Jess in Action][AskingGoodQuestions]
Craig Oliver
Greenhorn

Joined: Aug 25, 2003
Posts: 21
Hi Ernest. Thanks for reply.

To continue with your example, what if class A has no synchronized methods? ie if a(), x(), y() and z() are not synchronized.
1. Have we locked/synchronized anything?
2. Have we at least synchronized a() and no other threads can call a() on same object.

Reference material has mentioned ability to synchronize objects using block technique where methods in that class are not already synchronized.
Craig Oliver
Greenhorn

Joined: Aug 25, 2003
Posts: 21
Sorry to keep going on about this. I have been testing these concepts and have found results odd. Didn't seem to matter what object I synchronized on, but did synchronize code with block.

Consider below case. Even when I use synchronize(aString) did synchronize calls to localA.method1(). Thread 2 waits for thread 1 to complete method1(). Confused about relevance of object in brackets after synchronized keyword.

Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24166
    
  30

Surely you're familiar with the concept of a "relay race" as practiced in the Olympic Games. There are some number (four?) of runners on a team, but only the one who is holding the baton (a plastic stick, I think) is supposed to run. One person holds the baton, and they run around, and then hand the baton to a second person, who then becomes the runner, and so on.

Think of every Java object as having a unique baton of its very own. One and only one thread can hold a given object's baton at a time. You're required to be holding the baton before you can

  • enter any synchronized method of that object
  • enter any block synchronized on that object


  • In your example below, there's a single String object, and a thread must hold that String's baton to enter the synchronized block; therefore the Threads have to take turns.

    Note that people might look at you funny if you talk about batons. Instead, people use the term monitor, as in "This thread holds the monitor for that object." Means exactly the same thing.
    Craig Oliver
    Greenhorn

    Joined: Aug 25, 2003
    Posts: 21
    Ernest, thanks for your assistance.

    I am comfortable with the monitor (baton) concept. My query has been whether the object synchronized with a block of code had to have any relationship to the code within that block. From your response and my example it is now clear to me the object synchronized need have no relationship to code within the block.

    Thanks again.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Synchronized Block Of Code
     
    Similar Threads
    Synchronization around instance variables
    differences between synchronized blocks and synchronized() method
    Some Thread Synchornization questions ?
    Returning from synchronized
    Synchronized blocks