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

Hi,

Lately we've been running most of our continuous builds with TSAN. When we
updated to the JDK11 runtime, we started getting reports of a race when
handing a task to a ForkJoinPool. I see the same race when running with the
"refresh
<http://cs.oswego.edu/pipermail/concurrency-interest/2020-January/017048.html>"
ForkJoinPool (assuming that's what I still get when I download
http://gee.cs.oswego.edu/dl/concurrent/dist/jsr166.jar nowadays).

The very rough form of the code is executing a job like this:

class Job implements Runnable {
  boolean b = true;

  public void run() {
    if (!b) { ... }
  }
}

TSAN reports a race between the write of b (in the submitting thread) and
the read (in the pool thread).

After staring at ForkJoinPool code a little, I'm not completely clear on
whether there's necessarily a happens-before edge between the plain write
of the task
<http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ForkJoinPool.java?revision=1.355&view=markup#l926>
and
the acquire read
<http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ForkJoinPool.java?revision=1.355&view=markup#l1563>,
at least when the worker was already running beforehand. I see a subsequent
casSlotToNull
<http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ForkJoinPool.java?revision=1.355&view=markup#l1566>,
but that's a weakCompareAndSet
<http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ForkJoinPool.java?revision=1.355&view=markup#l837>,
so I don't think that helps
<https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/package-summary.html#weakCompareAndSet>
?

But there is so much going on in ForkJoinPool that I won't pretend to
understand -- some of which TSAN doesn't currently understand, either
(e.g., manual fences). Plus, even if there is theoretically a race here, I
don't know if any compiler/architecture would exploit it. (For what it's
worth, I couldn't actually observe a stale value in my limited testing,
even on PPC.)

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