Synchronized Block Of Code

[Craig Oliver]

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]

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 ]

[Craig Oliver]

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]

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

void someMethod(A a) {
  synchronized (a) {
    a.somethingElse();
  }
}

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

[Craig Oliver]

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]

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.

public class ClassA
{
public void method1()
{
  for (int i=0; i<5; i++)
  {
    try
    {
      Thread.sleep(1000);
    }
    catch (InterruptedException ex)
    {
      // ignore
    }
    System.out.println(Thread.currentThread().getName() + " :" + i);
  }  // end for
}    // end method1
}
 
public class MyRunnable implements Runnable
{
// Instance variables
ClassA localA;
ClassA anotherA;
String aString;
 
// Constructor
public MyRunnable(ClassA ina)
{
  localA = ina;
  anotherA = new ClassA();
  aString = "dog";
}
 
public void run()
{
  System.out.println(Thread.currentThread().getName() + " Started");
  doStuff();
}
 
public void doStuff()
{
  synchronized(aString)
  {
    localA.method1();
  }
}
}  // end class
 
public class Driver
{
public static void main(String args[])
{
  ClassA a = new ClassA();
  MyRunnable mr = new MyRunnable(a);
  Thread t1 = new Thread(mr);
  Thread t2 = new Thread(mr);
  t1.start();
  t2.start();
}
}

[Ernest Friedman-Hill]

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]

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.