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