Forum:

Programmer Certification (OCPJP)

synchronized threads

Ranch Hand

Posts: 49

posted 19 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

<html>
class Counter {
int v = 0;
synchronized void inc() { v++; }
synchronized void dec() { v--; }
}
public class Q7ed5 {
Counter i;
Counter j;
Counter k;
public synchronized void a() {
i.inc();
System.out.println("a");
i.dec();
}
public synchronized void b() {
i.inc(); j.inc(); k.inc();
System.out.println("b");
i.dec(); j.dec(); k.dec();
}
public void c() {
k.inc();
System.out.println("c");
k.dec();
}
}
</html>
ans:i.v is guaranteed always to be 0 or 1.
j.v is guaranteed always to be 0 or 1.

i just want to know,
suppose there is one object,it has three threads then is it possible that one thread is acceesing method a(),second thread acessing b(),& third thread accssing c()method simultaneously?

Simon Cockayne

Ranch Hand

Posts: 214

posted 19 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

Hi,

I think the question is: "Can different threads simultaneously access different synchronized 'things' within a class?".

The answer is yes and no. Since 'things' could be methods or blocks of code.

If a thread is accessing a method, which is marked as synchronized, the thread will need the lock of the object that is represented by the class the method is defined in. Ergo, no other thread would be able to access any other synchronized methods in the same class.

BUT...if you have blocks of code synchronised on different objects, then different threads could access those blocks if they could obtain the pertinent lock.

Cheers,

Si.

SCJP 1.4 (93%) SCJD (In progress. It can run, but it can't hide...)

Simon Cockayne

Ranch Hand

Posts: 214

posted 19 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

Hi,

You can try the example below and see that once one of threads enters one of the synchronized methods in the ZZ class, the other thread can't enter the other method until it has finished...

Cheers,

Si.

SCJP 1.4 (93%) SCJD (In progress. It can run, but it can't hide...)

Simon Cockayne

Ranch Hand

Posts: 214

posted 19 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

...and in this example you have synchronized blocks..

If you run it as it is since both methods are synchronized on lock1, different threads cannot run the methods concurrently.

BUT, if you change one of the methods to be synchronized on lock2, then they can.

Cheers,

Si.

SCJP 1.4 (93%) SCJD (In progress. It can run, but it can't hide...)

prajkta patil

Ranch Hand

Posts: 49

posted 19 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

hi simon,
very nice explanation u have given.
thanks a lot.
prajakta

Yingtao Jiang

Greenhorn

Posts: 13

posted 19 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

Hi, Simon,

I think you make a mistake here.

If a thread is accessing a method, which is marked as synchronized, the thread will need the lock of the object that is represented by the class the method is defined in. Ergo, no other thread would be able to access any other synchronized methods in the same class.

This is true only for static method. For instance method, the lock is on the receiver object. As long as the reciever object is different, two threads can concurrently enter synchronized method that operate on different object of the same class.

once one of threads enters one of the synchronized methods in the ZZ class, the other thread can't enter the other method until it has finished...

Please see the modified example of yours below.

From the running result, you can see that, thread-0 and thread-1 can concurrently run aMethod() and bMethod(). As sleep() method do not give up lock, this example demonstrate that the two thread keep two different lock, which belongs to two instance of the same class.

Hope I made my point clear.

SCJP1.4 SCJD1.4 (preparing)

Simon Cockayne

Ranch Hand

Posts: 214

posted 19 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

Ah yes...you are right of course. I don't know why I was merely illustrating the static case.

If the the lock is based on an object which is an instance of a class...then I think the methods could be accessed by different threads if they could obtain the lock on the appropriate object.

Cheers,

Si.

SCJP 1.4 (93%) SCJD (In progress. It can run, but it can't hide...)

With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.