Synchronized Blocks in Static Methods Confusion

[MasterChief]

Hi guys,
I was reading this: Java Synchronized Blocks

As I'm trying to get my head around the synchronized keyword.

My query is based on some simple example code below.

Query: If threadOne executes before threadTwo and invokes the "add" method which synchronizes on the class object will thead2 continue to be blocked from updating both the
instanceVariableInt and the class variable someOtherInt until the intrinsic lock on Test.class has been released? (threadOne has left the synchronized statement code)

public class Test {

	private static int value = 10;
	
	private static int someOtherInt = 50;
	private int instanceVariableInt = 100;

	public int add(int digit){
		synchronized(Test.class){
			value =+ digit;
		}

		return value;
	}

	public void printName(){
		System.out.println(Test.class.getName());
	}
	
	public void doSomething(){
		//Update instance variable
		instanceVariableInt += 50;
		
		//Update some other class variable
		someOtherInt = 70;
	}

	public static void main(String[] args) {
		final Test threadOne = new Test();
		final Test threadTwo = new Test();

		new Thread(new Runnable() {
			public void run() {
				threadOne.add(10);
			}
		}).start();

		new Thread(new Runnable() {
			public void run() {
				threadTwo.printName();
				threadTwo.doSomething();
			}
		}).start();
	}
}

Thanks :)

[jim829]

Other than main, you have no static methods. The way it is written, only the add method will block another method from continuing with that method until the object lock is released. The two variables you mentioned may be updated by other means by other threads at any time since they are not subject to any synchronization.

Regards,
Jim

[MasterChief]

Thanks for the quick response Jim.

So when synchronization is performed on the class itself, it does not prevent other class variables from being updated during the period when a thread has lock on the class?


I was reading this article and just had another related question to the synchronized statement.
Intrinsic Locks and Synchronization (The Java™ Tutorials > Essential Classes > Concurrency)

Synchronized Statements

Another way to create synchronized code is with synchronized statements. Unlike synchronized methods, synchronized statements must specify the object that provides the intrinsic lock:

public void addName(String name) {
    synchronized(this) {
        lastName = name;
        nameCount++;
    }
    nameList.add(name);
}

In this example, the addName method needs to synchronize changes to lastName and nameCount, but also needs to avoid synchronizing invocations of other objects' methods. (Invoking other objects' methods from synchronized code can create problems that are described in the section on Liveness.) Without synchronized statements, there would have to be a separate, unsynchronized method for the sole purpose of invoking nameList.add.

Question: If an object is used to call another method within a synchronized block, is there implicitly a lock on that object? From what I read above, I interpreted that if nameList.add was inside that synchronized block then there would be a lock on namelist and other methods would not be able to update it until that lock had been released. Is this interpretation correct?

Cheers,

[jim829]

So when synchronization is performed on the class itself, it does not prevent other class variables from being updated during the period when a thread has lock on the class?

Correct (except that threads don't have locks on the class, only on methods and synchronized blocks). Synchronization only affects simultaneous access to fields within the synchronized block when using the same lock (monitor).

Question: If an object is used to call another method within a synchronized block, is there implicitly a lock on that object? From what I read above, I interpreted that if nameList.add was inside that synchronized block then there would be a lock on namelist and other methods would not be able to update it until that lock had been released. Is this interpretation correct?

Locks only apply to synchronization. If an instance method is synchronized on this, then that instance may still access other methods as long as they are not synchronized or not synchronized on this.

Some of this may not be intuitive and my answers also depend on understanding what you are asking. I recommend you try some examples using two threads (perhaps main and one other). Use different or same locks on different methods or synchronized blocks. If the code does not do what you expect, then someone on this forum should be able to explain why. It is essential to try examples to ensure full understanding.

Regards,
Jim

[gimbal2]

Yay Paint Creativity time! Hi, I'm Gimby and I suck at Paint.

Lets illustrate a basic sketch of what you want to achieve and what you want to prevent when it comes to thread synchronization. This is a simple world in which there is a wall with a closed door and an open door; that wall is all that stands between the nasty outdoors and the object properties.



That door has only one key; each thread is allowed through one at a time and must pass the key on to the next thread waiting in line. The world is sane, each thread manipulates the object all privately and alone behind that wall. The other threads cannot interfere.



Until one day there is this evil thread that sees the open door and just decides to run through it without waiting for its turn to get the key. There is chaos, there are now two threads that can pull on the levers and push the buttons of the object at the same time. Before long, the object grinds to a halt with lots of black smoke. If only that evil thread had waited for its turn to get the key.



The end! (good god I hope this looks okay)

[Tolls]

A masterpiece!

[jim829]

Hi, my name is Thread! See Thread run. Run Thread run! Watch Thread muck things up.

Regards,
Jim

[MasterChief]

Hi Guys,
Thanks a heap for the help! I understand how it all works out now ( I think). Great diagram too!

Locks only apply to synchronization. If an instance method is synchronized on this, then that instance may still access other methods as long as they are not synchronized or not synchronized on this.

So each thread needs the intrinsic lock which it gets from the monitor to execute synchronized code and the reason in the quote above why instance methods may still access other methods as long as they are not synchronized or synchronized on this is that ONLY one thread can have the intrinsic lock so the invocations to other methods which are synchronized will be blocked until they can get a hold of that intrinsic lock themselves in order to execute the code. Is this understanding now correct?

One last curious question if you have 2 synchronized methods, but one synchronizes on this and the other synchronizes on the Class itself, are there 2 intrinsic locks which will allow an instance of the class to access both methods simultaneously?

Cheers :)

[jim829]

Is this understanding now correct?

Yes!

One last curious question if you have 2 synchronized methods, but one synchronizes on this and the other synchronizes on the Class itself, are there 2 intrinsic locks which will allow an instance of the class to access both methods simultaneously?

Why not try it yourself. For a class Foo, sync one block on this and one block on Foo.class and see what happens.

Regards,
Jim

[SurfMan]

Yay Paint Creativity time! Hi, I'm Gimby and I suck at Paint.

I am going to print this, and hang it at the coffee machine.

[gimbal2]

One last curious question if you have 2 synchronized methods, but one synchronizes on this and the other synchronizes on the Class itself, are there 2 intrinsic locks which will allow an instance of the class to access both methods simultaneously?

Watch your terminology there, this is a synchronized method:

public synchronized void thisMethodIsSyncedDude(){

}

What you are talking about is a method which applies synchronization.

public void thisMethodIsNotSyncedDude(){
  synchronize(lockObject){
     // ... but this part is
  }
}

Or perhaps you are talking about both? Its not really clear.

Ask yourself this: are this and SomeClass.class the same object with the same door?