On 08/08/2017 02:21 PM, Peter Levart wrote:
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
I know it can't be done any better than that, because
ConcurrentSkipListSet is not final. If it was final, clone() could use
private constructor to construct a clone. But the same can be done at
least for objects of ConcurrentSkipListSet runtime class:
if (getClass() == ConcurrentSkipListSet.class) {
return new ConcurrentSkipListSet(clonedMap);
} else {
// proceed as is
}
Hm...
An alternative would be to use explicit fence before the end of clone()
Regards, Peter
