Re: how to make this code thread safer?
www wrote:
The code below is completely fine if running on single-thread
environment. But it could break if running on multi-thread environment.
I have added my analysis as comments in the code to show my
understanding why it is not thread safe. My real code, with a pattern
like the code shown here, indeed breaks once in a while with Null
Pointer Exception in multi thread run. Do you think my analysis is
correct? Can you help me on making this code thread safer?
The simplest fix is to just add "synchronized" to the method
declarations. This will cause each method to acquire the instance's
monitor during their execution, ensuring that only one thread can be
executing either method at a time.
Another alternative would be to use the "synchronized" statement to the
code inside each method. Assuming the "isAbsent()" method isn't
affected by the "other code" or the "doA()", "doB()", or "doC()"
methods, that could look like this:
public class MyClass
{
private Person tim = new Person("Tim");
private Person tom = new Person("Tom");
private final Object lock = new Object();
public void doThis
{
this.checkSomething();
synchronized (lock)
{
if(tim != null) //thread "A" is running "doThis()" and tim is not
null at this moment
{
... //other code
tim.doA(); //tim is NULL all of sudden, and NPE is thrown. I
think it is due to another thread running checkSomething()
tim.doB();
tim.doC();
}
}
}
public void checkSomething() //thread "B" is running checkSomething()
{
if(tim.isAbsent())
{
synchronized (lock)
{
tim = null;
}
}
if(tom.isAbsent())
{
tom = null;
}
}
}
That would have a similar effect, but would only synchronize in thread
"B" when the instance field actually has to be changed. It would still
ensure that the field cannot change between the time thread "A" checks
for the "null" value and when it tries to use it, but has the potential
for being more efficient because in theory, less contention would occur
("contention" being when two different threads actually do need to
acquire the same lock at the same time).
Note the use of a dedicated object reference for synchronization. In
general, it is poor practice to use the "this" reference for
synchronization, though that's what declaring a method as "synchronized"
does. It's not the end of the world to use "this", but doing so "leaks"
some of your implementation, and introduces the possibility of some
other code not related to your own taking the same monitor, increasing
contention as well as the complexity of the locking scenarios.
Those are the simplest techniques available in Java, and for the example
you've given are probably the most appropriate anyway. As you learn
more about concurrent programming, you'll probably want to look at the
other synchronization features in Java, found mainly in the
java.util.concurrent package.
Pete