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

Chris Povirk via Concurrency-interest <[email protected]> Thu, 16 Jul 2020 21:10:05 -0400
Newsgroups gmane.comp.java.jsr.166-concurrency
Message-ID <CAEvq2nrKRaYfQWV2oyBcfpRqeM=onb72Xoa1cFCUpBZW5YVVJA@mail.gmail.com>
Thanks. My impression is that even a <setRelease,getAcquire> pair is enough
to establish the happens-before relationship. (I say that mainly from
skimming http://gee.cs.oswego.edu/dl/html/j9mm.html, not from any deep
understanding. I see that that doc even recommends against the term
"happens-before" :)) And for what it's worth, that's enough to satisfy our
TSAN setup, too.

The most interesting change relative to JDK8 (which is what we were using
before) might be on the *write* side: Where JDK8 always(?)
used putOrderedObject (apparently similar to volatile) or similar, JDK11
sometimes uses only(?) that plain write I linked above.

It occurs to me only now that I'm writing this that, thanks to the power of
--patch-module, I could probably tweak the ForkJoinPool source to use a
"stronger" write and see if the TSAN failure goes away. Maybe I'll try that
if I get a chance....

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