Re: [boost] [interprocess] Boost.Thread developers willing to help on interprocess condition vars?

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-09-28 11:22:50

"Phil Endecott" <spam_from_boost_dev_at_[hidden]> writes:

> Anthony Williams wrote:
>> Ion Gazta?aga <igaztanaga_at_[hidden]> 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