Interview question...

[dennis wong]

Two threads try to access two methods in a class the same time. One mothod is static, the other is regular method. There are shared resources inside both method and both threads are going to manipulate the resources. Question: If both mothods are synchronized, is there a risk for thread-safty?

[Reid M. Pinchback]

Originally posted by dennis wong:
and both threads are going to manipulate the resources

If both static and instance methods are sharing resources in the class, then those resources are themselves static members (or the static method couldn't access them in the first place). Whether or not there is a race condition is determined by what the static and the instance method each use for their monitor. If both synchronize on the class, or on some static object reference held by the class consistently used as a defacto monitor by both instead of the class object itself, then there is no race condition.

[Eddy Lee Sin Ti]

The shared resources still would be accessed by both threads if each of the synchronized methods called by different thread at the same time. Ya, there will be thread safety issue.

[Henry Wong]

Question: If both mothods are synchronized, is there a risk for thread-safty?

Since this is an interview question, I will assume that it is testing something very specific. I am guessing it is targeting whether the candidate understands what is happening under-the-covers when a method is sychronized.

Basically, when you synchronize a method (that is not static), it will use the "this" object of that method as the synchronization lock. No other synchronization method or block that uses the same object will be able to execute in parallel.

A static method does not have access to a "this" object. Instead, it uses the "class" object of the class which the method is part of.

I am assuming that the candidate needs to understand that these are two different object, and hence, it is not thread safe.

Henry

[dennis wong]

Thanks! My answer is:

Since both mothods try to manipulate the same common data, either in a Hashmap or other container, we can see that the common data is not local variables and without assigned different java stack space. So these data are simply in a share heap on the same JVM. When two threads try to access the same time and manipulate the data, there is a thread-safty issue no matter both method synchronized or not, static or not.

The solution would be synchronizing the resource container for the code block which manipulates the common data in both methods:

synchronized(mapX){
//data manipulation..

}

What do you think the answer?

[ March 19, 2006: Message edited by: dennis wong ]
[ March 19, 2006: Message edited by: dennis wong ]

[Andreas Schaefer]

A static method that is synchronized is trying to obtain a lock on the Class instance (the object that you get back when: MyClass.class). The non-static method is trying to obtain a lock on the instance.
Therefore the two threads can access both methods at the same time and you could have a race condition.

A way to solve that issue is not to synchronize the method by use a synchronized block and using the same object to lock on like:
private static Object lock = new Object();

public static void xyz() {
sychronized( lock ) {
...
}
}
public void abc() {
synchronized( lock ) {
...
}
}

Of couse you could also use another share object that fits the need for your problem.

-Andy

[Mahadevan Gorti SS]

Hi,
It depends upon what exaclty we are doing in the static/instamce mthod. In case of instance method are we calling/in-future-will-call some other static synchrozed methods(direct-call/indirect-call)

Question is have we these two methods(on Class Namex XXX )
[[[
static Map shared1;
static Map shared2;

public static synchronized void methodS(){
call_3();
call_n();/etc
}

public synchronized void methodI(){
call_1();
call_2();
call_n();//etc
}

Where the shared resouces are maipulated/MAY-get-manipulated-in-future in call_X methods.
-------------------------------]]]

In the aboce case, best way avoid dead-locks is, simply synchronize the resources on XXX.class(this object's locks is being taken by static methods). So ONE POSSIBLE solution is:
[[[
// Here we always take XXX.class 's monitor first (in both methods)
public static synchronized void methodS(){
call_3();
call_n();/etc
}

public synchronized void methodI(){
synchronized(XXX.class){
call_1();
call_2();
call_n();//etc
}
}

]]]


If any other way of taking locks may lead to dead-locks -- there is/can-be possibillity of locking in reverse order). For example
[[[
// in static methid lock order is XXX.class --> lockO
static Object lockO=new Object();
public static synchronized void methodS(){
synchroznied(lockO){
call_3();
call_n();/etc
}
}

// in instance methid lock order is lockO --> XXX.class
// So there is possibility of dead-lock
public synchronized void methodI(){
synchronized(lock)
call_1();
call_2();
call_n();//etc
}
}

public static synchronized void call_n(){/// DANGER we have taken XXX.class object's monitor. SO order od locking is reversed in instanc method
}

]]]