synchronized

[Aashima Arora]

  

public class chess implements Runnable
{ public void run()
  {   move( Thread.currentThread().getId());

   }
 synchronized void move(long id)
  {
	  System.out.println(id+" ");
	  System.out.println(id+" ");
  }


  public static void main( String args[])
  {
	  chess ch = new chess();
	  new Thread(ch).start();
	  new Thread(ch).start();


   }
}
  

Oh thee ranchers ! help me once again

iam super confused about 1 particular thing

synchronized keyword locks on whattt !!
does it lock on the runnable object here??
because if here i replace ch in the latter part of the code with another runnable object new chess(), then i get output like { 8,9,9,8} but if i use the same runnable object then i get consistently{ 8,8,9,9} ... when its supposed to be sychronized (this), what this!! is i cant spot !
so just tell me what does it actually lock on!

lock on runnable object , or some other instance

[Marco Ehrentreich]

Hi Aashima,

the synchronized keyword on a non-static method uses the so-called intrinsic lock of the object it belongs to (every object in Java has one). So it's clear that there are TWO locks involved if you have two instances of your runnable class I hope that helps to answer your question.

As an additional note: Each class has an intrinsic lock, too. That's why I mentioned non-static methods above. This means that synchronized static methods called on an object always use the one and only intrinsic lock of the CLASS not the object.

Marco

[Aashima Arora]

hey marco ,
thanks so much for replying ! but i still have a little confusion. You mean to say that here the object resposible for calling the synchronized method is the runnable object ??
is it not meant to be a class instance ? it can be anything ?

[Marco Ehrentreich]

It's not about the responsibility for the synchronized keyword. That's a Java language feature implemented in the JVM.

The non-deterministic problems (the more or less random output) you have seen with multiple instances of your Runnable class is related to problems with multiple locks in general. It's not specific to the Runnable or a particular class or interface.

If you just use the synchronized keyword in the method declaration it means "synchronize on the objects intrinsic lock". Because the synchronized method is inside your chess class (which implements Runnable) it uses the intrinsic lock of the chess object(s). If you have one object of class chess there is obviously only one lock. If you have two chess objects there are two locks. If your code requires that the method move() synchronizes on only ONE lock to work correctly when called inside multiple threads it won't work if there are TWO locks.

Mutli-threading is a very complicated topic, so it's just not easy to explain in here in detail. But you can experiment with another way to use the synchronized keyword. It's more flexible to use a synchronized block which makes the lock explicit. The following code is equivalent to using a simple synchronized method:

void move(long id) {  
  synchronized(this) {
      System.out.println(id+" ");  
      System.out.println(id+" ");  
  }
}

Using "this" as a lock means using the intrinsic lock of the object this method belongs to. But you can use any object as a lock in a synchronized block. So you can easily create a completely different object (as simple as "Object lock = new Object();") and use this object as a common lock for each instance of your chess class.

I hope this helps a little bit to enlighten this problem. As I said it's really difficult to explain (and understand).

Marco

[Aashima Arora]

Thanksssss a toonn !! I never knew it works like that !! it wasnt that clearly explained in K & B too !
Thanks once again :-)))

[Marco Ehrentreich]

I'm glad that I could help you (a little bit)

But keep in mind that the topic is very complex and my explanations were VERY rough. The details of multi-threading are way more complex. Dealing with the synchronized keyword and synchronizing in general is not as easy as it may seem, at least not if you expect your applications to work correctly.

Of course it's part of the SCJP but for practical usage you may want to have a look at the "java.util.concurrent" package. There are many helpful utilities which provide higher-level abstractions to handle mulitple threads without worrying too much about lower-level details like locks, synchronization, thread creation etc. But you still should understand the consequences of multi-threading in Java so it won't be a waste of time to learn the details, too.

Marco