PromiseTask.isCancelled performs an unsynchronized read

In #9744 @njhill changed PromiseTask.isCancelled to:

https://github.com/netty/netty/blob/fcf55fcf718af1e4cae85eb86cdb679094186aed/common/src/main/java/io/netty/util/concurrent/PromiseTask.java#L180-L182

But task is just a plain field:

https://github.com/netty/netty/blob/fcf55fcf718af1e4cae85eb86cdb679094186aed/common/src/main/java/io/netty/util/concurrent/PromiseTask.java#L65

A race detector is noticing this unsynchronized read/write.

The write is occurring in clearTaskAfterCompletion(), which does mention the potential for a write race, which does seem likely to be minor:

https://github.com/netty/netty/blob/fcf55fcf718af1e4cae85eb86cdb679094186aed/common/src/main/java/io/netty/util/concurrent/PromiseTask.java#L114-L123

I’ve not spent too much time looking at it, but it is unclear to me why task == CANCELLED is even checked in isCancelled(); it seems like DefaultPromise.isCancelled() should be enough. It sort of seems like the semantics of isCancelled() are being changed to be more of a isDone(). But I don’t think I understand the code enough to know how serious this race is.

[ejona86]

There used to be more failures in Netty, but many of them have been fixed. I did find a whitelist and it appears the only Netty race whitelisted is from io.netty.util.Recycler$WeakOrderQueue.transfer (not saying such a race still exists). But I do see a reasonable number of races ignored for the java standard library. That might be to just allow the tool to be used; stop new issues from being introduced and clean up preexisting issues over time.

In any case, if we don’t get much performance benefit it is probably best to remove the optimization. If we can show the benefit then we can try to get on the whitelist.

[normanmaurer]

Here we go https://github.com/netty/netty/pull/10066