On 19/06/2018 3:08 PM, Martin Buchholz wrote:
Latest version looks like this:
public Object clone() {
try {
@SuppressWarnings("unchecked")
CopyOnWriteArrayList<E> clone =
(CopyOnWriteArrayList<E>) super.clone();
clone.resetLock();
+ // Unlike in readObject, here we cannot
visibility-piggyback on the
+ // volatile write in setArray().
+ VarHandle.releaseFence();
return clone;
} catch (CloneNotSupportedException e) {
// this shouldn't happen, since we are Cloneable
throw new InternalError();
}
}
The store we worry about is a hypothetical subsequent racy publication
of the new object, so we put the release fence at the end of the
pseudo-constructor.
Thanks for clarifying.
I'm unsure why we're trying to make this particular class
unsafe-publication-proof, but I guess it's generally a good thing.
David
On Mon, Jun 18, 2018 at 9:01 PM, David Holmes <david.hol...@oracle.com
<mailto:david.hol...@oracle.com>> wrote:
On 19/06/2018 6:01 AM, Doug Lea wrote:
Hang on! A releasing store does the "release" before the store not
after it. The whole point being if you see the result of the store
then you are guaranteed to see all previous stores. The above can
reorder the lockField store with whatever stores come before it.
David
-----
