|
Boost : |
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2020-05-17 12:30:31
Andrey Semashev <andrey.semashev_at_[hidden]> wrote:
> On 2020-05-16 21:35, Phil Endecott via Boost wrote:
>> Phil Endecott wrote:
>> Andrey Semashev <andrey.semashev_at_[hidden]> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk