tsan lock-order-inversion reports about copper

[atollk]

I'll have to have a look at this. But from a first view, it might just be that this is a use case which I haven't thought of before that cannot be done safely with select. So unless I'm mistaken, I see two options:

First, accept that select can't do that and update the documentation accordingly. vselect can still be used and should work fine here.

Second, try and fix select to allow it. However, I actually don't see any way to do that to actually fix every case. For every change I can think of, I can find a similar example which would break it again.

Unless you see a third option.

[sethalves]

If you move the push() to the body of the while loop, tsan doesn't complain. I was hoping that some reordering could fix this, but if not, I can live with it.

[atollk]

Right. The issue lies in how select works and also has to work. For popping from the channel, it's not as bad, but you could make a similar example for pushing to it. As soon as a channel is chosen to be "selected", it has to be locked for the entire time until the select operation completes. This is due to a few reasons:

If the channel is selected for a push operation, it must be open. If the channel were to be unlocked within the select operation, i.e. before the push completes, it could be closed in the meantime by another thread. Other threads might then recognize the channel as being closed and break out of some loops. When the push and select then finally finish after that point, the data that was pushed into the channel is lost.

Moving push out of the select removes that problem because the channel doesn't have to be locked at that point anymore. Or, as I said, vselect accomplishes the same thing.