"Phil Endecott" <spam_from_boost_dev@chezphil.org> writes:
Anthony Williams wrote:
Ion Gazta?aga <igaztanaga@gmail.com> writes:
Peter Dimov wrote:
Ion Gazta?aga wrote:
Does this support building those objects in mapped files, rebooting the system, mapping the file again again and continue working? [snip] However, I would not expect the mutex to survive a reboot --- there might still be data in the file, but I would expect a process-shared mutex to have at least some portion that was a handle to a kernel object, and the kernel object would go away with a reboot.
I have no idea what the POSIX spec requires or what most implementations actually do. But I believe that the Linux implementation, using the futex() system call, probably can survive a reboot as it has no permanent kernel component. The kernel only gets involved when a process finds the mutex locked, and needs to wait. See 'man 2 futex'. Of course the pthread_* functions, which wrap the futex() functionality, may make it impossible to exploit this behaviour.
I can see that working. Actually, my idea for using a UUID on Windows would work the same. However, this would only work for unlocked mutexes --- a locked mutex would potentially remain locked, but with no clear owner, or it might be unlocked, depending on how the state was stored. Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL