Re: (hypothetical? bogus?) TSAN failure reported in ForkJoinPool (JDK11 and "refresh" versions)

Thanks.

The puzzling thing to me has been the "guaranteed to follow eventually"
part: As best I can tell, a worker thread can potentially see the
submitting thread's plain write without any subsequent action by the
submitting thread. (Some evidence: I edited ForkJoinPool so that it will
randomly decide to loop infinitely immediately after the write sometimes.
With that change, I sometimes still see a worker thread pick up the
submitted task during the submitter's infinite loop. Or at least I
*think* that's
what I'm seeing.) Thus, we can't be relying on subsequent work by the
submitting thread.

So, to provide the edge we need, I gathered that the *worker thread* has to
do something. And I see now that I was misunderstanding its
weakCompareAndSet: I had read the docs on (JDK8)
AtomicReference.weakCompareAndSet
<https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/AtomicReference.html#weakCompareAndSet-V-V->,
which provides no ordering guarantees. But I see that that name has been
deprecated as misleading
<https://docs.oracle.com/javase/9/docs/api/java/util/concurrent/atomic/AtomicReference.html#weakCompareAndSet-V-V->,
and the *VarHandle* weakCompareAndSet
<https://docs.oracle.com/javase/9/docs/api/java/lang/invoke/VarHandle.html#weakCompareAndSet-java.lang.Object...->
(the
one that's used in ForkJoinPoo.scan
<http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ForkJoinPool.java?revision=1.355&view=markup#l1566>
) *does* provide ordering guarantees. Then, while I don't know the details
of mixing a plain write with an acquire read + volatile CAS, I can imagine
that any writes prior to the plain write in the submitting thread are
guaranteed visible to the worker thread after its successful CAS.

However, this still feels a little iffy: Since the submitter is performing
only plain writes, it's not obvious to me what would prevent it from
writing the task to the queue (and then being delayed arbitrarily long)
before writing the boolean flag. Perhaps the worker's weakCompareAndSet
somehow fails "spuriously" in that case?

_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest