JDK-8044616 : Clients of Unsafe.compareAndSwapLong need to beware of using direct stores to the same field
- Type: Bug
- Component: core-libs
- Sub-Component: java.util.concurrent
- Affected Version: 8,9
- Priority: P4
- Status: Closed
- Resolution: Duplicate
- Submitted: 2014-06-03
- Updated: 2015-11-09
- Resolved: 2015-09-21
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
| JDK 9 |
|---|
9 b88Resolved  |
Related Reports
|
Duplicate :
|
Description
sun.misc.Unsafe provides a set of API's for atomic updates to fields including Java long fields. Not all platforms support the atomic compare-and-set for 64-bit values in which case Unsafe will fallback to a locking scheme. The locking scheme can not enforce atomicity with respect to direct stores to the field from Java code, so clients of this API should avoid such direct stores. I did an audit of j.u.c to see which classes use Unsafe.compareAndSwapLong and whether they allow direct setting of the field that is cas'd. The following classes (and any apps that use them) are potentially broken because they allow that: - AtomicLong - AbstractLongQueuedSynchronizer - StampedLock The set-style operations and any internal direct sets (eg in StampedLock) would need to be rewritten to use Unsafe.putLongVolatile. Any use of putLongVolatile should be factored and guarded by "supports_cx8" so that the JIT can inline the direct volatile store when it is available. NOTE this only affects platforms which do not support 64-bit CAS. None of the mainline OpenJDK platforms are affected by this. Also note that other j.u.c classes already take this into account, either ensuring Unsafe.xxx updates only or even using Java-level locking in the case of AtomicLongFieldUpdater.
Comments
|