Ticket #136 (closed enhancement: fixed)
Synchronized blocks on expressions of type Object
|Reported by:||Bernhard Haumacher (haui at haumacher dot de)||Owned by:|
If a block is synchronized on an expression of type Object, the complier can not decide statically, whether the synchronization will be a remote or a local synchronization at runtime.
The current transformation creates a double synchronization if the object the synchronization is performed on is a remote object at runtime. If the object is a remote object at runtime, first a lock is acquired on the implementation object, and afterwards a synchronization is performed on the handle object. This synchronization scheme is OK for mutual exclusion, but it does not work signaling on remote objects. If one threads waits in a synchronized block on a remote object, only the lock at the implementation object is released while waiting. Since this thread still holds the monitor of the handle object, another thread that has a reference to the same object handle can not aquire the remote monitor for signaling, because it is blocked at the local handle.
At runtime the decision must be made, whether the object the synchronization is performed on is a remote or a local object. If it is a local object, only a local synchronization should be performed. If the object is a remote object at runtime, only the lock of the remote implementation object should be set, and no local synchronization should be happen. The problem could be solved in three ways: 1. Duplicating the code of the synchronized block (one copy with local and one copy with remote synchronization). 2. By transforming the synchronized code into a private method of the same class that is called from within a locally synchronized block, or from within a remote monitor access/release pair. 3. By directly creating Java ByteCode and creating a local subroutine for the code within the synchronized block and calling that local subroutine from within local synchronization or from within a remote monitor access/release pair. Possibility 3 is bad, because it breaks the source to source transformation. Possibility 2 is difficult, because it requires a data-flow analysis to identify the values used within the synchronized block and those that may escape the synchronized block. The transformation into a separate method is not possible, if more than one value must be returned from that method. Therefore possibility 1 seems to be the best one.
fixed since 1.06d.
- Severity changed from normal to blocker
- Component changed from JP trafo to uka.lang
- Priority changed from normal to low
- Version set to 1.09c
- Milestone changed from 1.06d to JPlater
- Type changed from defect to task
- Severity changed from blocker to critical
- Component changed from uka.lang to uka.gm
- Priority changed from low to normal
- Version changed from 1.09c to 1.04c
- Milestone changed from JPlater to 1.03h
- Type changed from task to enhancement
- Severity changed from critical to major
- Component changed from uka.gm to uka.karo
- Priority changed from normal to highest
- Version changed from 1.04c to 1.00
- Milestone changed from 1.03h to 1.07g
- Type changed from enhancement to defect