Re: Java Synchronization: Changing the lock-reference
flythefriendlyskies@gmx.de wrote:
We run on IBM JVM 1.4.2
For concurrency work you might try the backport of java.util.concurrent.
Or much better upgrade to 1.5 - it is much better tested than 1.4 and
the Sun version was released over two years ago.
public Object get() {
Object value = getInternal();
if (value instanceof String) {
return value;
}
synchronized (value) {
value = dcl.get(KEY);
if (value instanceof String) {
return value;
}
dcl.put(KEY, VALUE);
}
return VALUE;
}
public Object getInternal() {
Object result = dcl.get(KEY);
if (result == null) {
result = new Object();
dcl.put(KEY, result);
}
return result;
}
What is dcl? A synchronised HashMap or Hashtable?
The first obvious problem is the getInternal is a race. Either
synchronise on the same key as dcl is using (if it using a single lock)
or use the java.util.concurrent.ConcurrentMap (or backport) and putIfAbsent.
Have you looked at the stack traces? They might make more sense if you
lock on an object having a giveaway class name.
So getInternal might look like:
public Object getInternal() { // internal and public??
synchronized (dcl) {
Object result = dcl.get(KEY);
if (result == null) {
// You may want to make Lock a static nested class.
class Lock { }
result = new Lock();
dcl.put(KEY, result);
}
return result;
}
}
Or with ConcurrentMap:
public Object getInternal() { // internal and public??
// Not necessary,
// but optimisation assuming KEY is usually present.
Object result = dcl.get(KEY);
if (result != null) {
return result;
}
// You may want to make Lock a static nested class.
class Lock { }
result = new Lock();
Object old = dcl.putIfAbsent(KEY, result);
return old==null ? result : old;
}
The second problem is potential deadlocks or at least unrelated locking
interference.
How does the rest of the program use those objects as locks? String in
particular could be locked by anyone.
Assuming dcl is synchronised in someway, you have nested synchronisation
(always something to be exceedingly careful about). You synchronise on
value (whatever that might be) and then on dcl.
If you aren't careful about what you synchronise on then you can see odd
effects. Something else might hold the lock for an extended duration.
Other code wait/notify mechanisms might interfere (infamously, Thread is
synchronised and notified when it exits).
Tom Hawtin