Andrey Semashev
On 2020-05-16 21:35, Phil Endecott via Boost wrote:
Phil Endecott wrote: Andrey Semashev
wrote: * PTHREAD_MUTEX_ROBUST might be part of the solution. That seems to require the non-crashed process to do clean up, i.e. we would need to record whether the crashed process were reading or writing and react appropriately.
You can't do that reliably because the crashed process could have crashed between locking the mutex and indicating its intentions.
I don't follow. Say I have a bool in the mutex called being_written. It's initially false, the read lock doesn't touch it, and the write lock does:
lock() { m.lock(); being_written = true; memory_barrier(); } unlock() { memory_barrier(); being_written = false; m.unlock(); }
If the process crashes between locking and setting being_written, then the process doing the cleanup will see being_written = false, and that's OK because the crasher hadn't actually written anything.
What if the writer crashes in unlock(), between being_written = false and m.unlock()?
Not a problem; the writer completed its changes and the state is consistent. Regards, Phil.