Unix: RwLock is incorrect

[RalfJung]

I think the sys::unix::rwlock implementation is incorrect in the sense that it has undefined behavior, for two reasons:

• The access to write_locked is not properly synchronized: In read, we access write_locked even if pthread_rwlock_rdlock failed. This is fixed.
• Worse, POSiX read-write locks have UB when the thread holding the write lock attempts to acquire it again -- and yet nothing is stopping exactly that from happening in write. If we really want to use POSIX rwlocks, I think we have to implement a reentrancy detector. (And then maybe we also want to use that for mutex, so that we can use the static initializer and the most efficient code path?)

[RalfJung]

I based my statements on http://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_rwlock_wrlock.html. @sfackler points out that at https://linux.die.net/man/3/pthread_rwlock_wrlock, behavior for re-acquiring the write lock is defined as "may deadlock" -- but not UB. However, we also use this implementation on non-Linux platforms, e.g. macOS.

[sfackler]

macOS does explicitly identify the behavior as undefined.

[RalfJung]

FWIW, RwLock is also UB on Windows -- actually, even Mutex is wrong there.

I think we should stop using the platform-specific implementations, and just roll our own based on thread (un)parking.

[sfackler]

cc @alexcrichton - we talked about this a bit during RustConf.

[alexcrichton]

I agree that we're basically at the point that there's a ridiculous amount of constraints from OS primitives that the only program which doesn't have undefined behavior is correct ones, and we all know how often we write correct programs.

All these discussions are spread out over a number of issues though and PRs, and it's really difficult to keep it all in my own head at least. "This is UB" is a very strong motivation for reimplementing the standard library's primitives, but I think the scale of a change such as this would probably want to go through the RFC process. Such an RFC would be a great location to centralize all the various hazards of OS primitives and how unreasonable it is for us to try to appease all possible implementations. That in turns provides excellent motivation for alternative strategies.

[retep998]

You mean like this RFC? rust-lang/rfcs#1632

[RalfJung]

Correction: Even some correct programs are UB. Reentrancy on the read lock of an RwLock is a perfectly reasonable thing to do, and yet Windows declares it UB.

Whether reentrancy that leads to deadlocks is "correct" is open for interpretation, I guess ;) but anyway, it is safe, and hence "correct enough" for UB to be critical.

[alexcrichton]

I've opened an internals post to continue more long-form discussion on the topic of continuing to fix these issues.