Hi Martin,
Just a purely theoretical question...
On 08/08/2017 02:06 AM, Martin Buchholz wrote:
Need to fix
1. JDK-8185830 <https://bugs.openjdk.java.net/browse/JDK-8185830>
ConcurrentSkipListSet.clone() fails with UnsupportedOperationException
http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/
(It would be nice if we could submit a jdk9 backport now instead of waiting)
Regarding ConcurrentSkipListSet.clone()... The 'm' field is final
presumably to allow "safe" publication of ConcurrentSkipListSet objects
to other threads via data races.
clone() O.T.O.H. uses Field.setAccessible(true) on a final field,
followed with Field.set(), which amounts to Unsafe.putObjectVolatile().
Is this equivalent to volatile write? Is it possible for a normal write
of a reference to a cloned ConcurrentSkipListSet (i.e. publication via
data race) to bubble up before the volatile write of 'm' field inside
the clone and consequently allow an observer of a reference to the clone
to modify the backing map of the original ConcurrentSkipListSet?
Regards, Peter
