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 10:30:07

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?
>> Is this guaranteed by POSIX? Which specific cases need to be supported? How
>> would a condition that is rebooted in the middle of four threads waiting
>> and one thread somewhere inside notify_one be able to resume operation?
>
> At least in the classic "UNIX Network Programming, Volume 2, Second Edition:
> Interprocess Communications" (W. Richard Stevens) there is a chapter
> explaining POSIX message queues and an implementation using Memory mapped
> I/O and posix mutexes and condition variables.
>
> Whether this is officially supported by POSIX, I thought it was, but I can't
> find an explicit comment on this. Is there any POSIX expert out there that
> can solve this? It seems that Solaris + Linux and other UNIXes support it
> without problems.

POSIX mutexes that have PTHREAD_PROCESS_SHARED "can be operated on by any
thread that has access to the memory where the mutex is allocated, even if the
mutex is allocated in memory that is shared by multiple processes". If that
memory is backed by a memory-mapped file, then I guess one way to get access
to the memory is to map the file. Even so, I wouldn't like to guarantee it.

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 expect the same to be true of condition variables. There is certainly
nothing in the POSIX spec that says you can save a mutex to disk and read it
back again. In fact, there is explicit wording in the rationale to suggest
that some implementations may just store a pointer to the actual data
structure --- in which case, writing it to disk and reading it back is not
going to work, as the pointer will be invalid.

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