Boost logo

Boost :

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-07-08 08:46:20

Hi Dmitry,

> 1. If you hasn't semaphore support in your glibc libraries (in my case
> it was without TLS) "sem_open" function will return (sem_t*)0 instead of
> (sem_t*)-1 as it is described in my system header "semaphore.h".
> Plese correct file "shared_memory.hpp" for using SEM_FAILED macros.

Thanks! It seems that ((sem_t *)-1) was explicity used in some
implementations and was documented like this, but you are right,
OpenGroup specifies that the return value is SEM_FAILED. Corrected in

> 2. Unclear sinuation. I wrote bugous example program where I write some
> data in shared_message_queue in infinity cycle without any timeout.
> If you stop program by Ctrl+C "boost_shmem_shm_global_mutex" stays in
> locked state so program will not work from second start. If you include
> some timeout in cycle then program will work properly.

This is strange. The infamous "boost_shmem_shm_global_mutex" global
mutex is used to implement atomic system-wide initializations, and can
be left locked if a process crashes in the atomic initialization (that's
why I plan to use file locks in Boost.Interprocess, that are guaranteed
to be unlocked automatically when a process crashes), but with a
shared_message_queue this just can happen when opening, creating or
destroying one. But never while sending receiving messages, since it's
not used in those cases.

The problem is that the message queue has a process-shared mutex and a
condition variable constructed in shared memory to implement the queue
and if you crash a process while holding the mutex, the queue is left in
a corrupted state. I can't do anything to solve this, since I would need
the OS to unlock all the resources if the owner dies. Nevertheless this
does not guarantee anything, since the message queue state might be
wrong (the program is crashed while manipulating internal queue
pointers, for example).

I'm sorry to tell you that POSIX async signals are really difficult to
combine with a portable interprocess syncrhonization library. I would
need help from UNIX experts to know what should I do to provide signal
safe synchronization objects. Masking the signals just when entering the
message queue functions does not seem very nice, since a process can
stay blocked while a message arrives. Any ideas?



Boost list run by bdawes at, gregod at, cpdaniel at, john at