mmap'ed robust mutexes and possible undefined behaviour
Tue Nov 25 20:57:00 GMT 2014
On Tue, Nov 25, 2014 at 08:26:33PM +0100, Florian Weimer wrote:
> * Florian Weimer:
> > * Carlos O'Donell:
> >>> 1. we open a file.
> >>> 2. we mmap it and use that mem to store a robust mutex.
> >>> 3. we lock the mutex.
> >>> 4. we munmap the file.
> >>> 5. we close the file.
> >> Undefined behaviour.
> >> This results in undefined behaviour since the allocated storage for
> >> the mutex object has been lost. You need to keep that storage around
> >> for the robust algorithms to work with. Without any data you can't
> >> do anything.
> > Some might expect that the mutex enters inconsistent state when the
> > mutex is unmapped, not just on process death. Then the data would
> > still be available at the time the state change would need to happen.
> Ugh. I should have said that this would be an extension, it's not
> required by POSIX.
yeah, like Solaris' non portable version:
Â«When the owner of a mutex with the PTHREAD_MUTEX_ROBUST_NP
robustness attribute dies, or when the process containing such a locked
mutex unmaps the memory containing the mutex or performs one of the
exec(2) functions, the mutex is unlocked.Â»
(Not so) Random fortune:
22:22 < m4rgin4l_> hendrix no tocaba la viola, violaba la toca
More information about the Libc-help