File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Threads and Synchronization and the fly likes Interview question... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Interview question..." Watch "Interview question..." New topic
Author

Interview question...

dennis wong
Greenhorn

Joined: Mar 18, 2006
Posts: 2
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
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
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.


Reid - SCJP2 (April 2002)
Eddy Lee Sin Ti
Ranch Hand

Joined: Oct 06, 2005
Posts: 135
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.


SCJP, SCWCD, SCJWS, IBM 700,IBM 701, IBM 704, IBM 705, CA Clarity Technical<br /> <br /><a href="http://eddyleesinti.blogspot.com" target="_blank" rel="nofollow">http://eddyleesinti.blogspot.com</a>
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 19073
    
  40

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


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
dennis wong
Greenhorn

Joined: Mar 18, 2006
Posts: 2
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
Ranch Hand

Joined: Feb 13, 2006
Posts: 63
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
Greenhorn

Joined: Jan 31, 2006
Posts: 18
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
}

]]]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Interview question...