Hi, I am trying to use Boost.Interprocess to get N processes (senders) to send data to one receiver through shared memory. The receiver has to be the one that initializes the shared memory, so no senders can be "let in" before the receiver has completed initialization. I can't guarantee the order that the processes are starting in. To do this I have both the receiver and the senders create_or_open a named_semaphore with 0 as initial value. The senders then immediately do a wait on the semaphore, but the receiver goes ahead and initializes the memory and then does a post on the semaphore. This lets the first sender in, which can then initialize itself and then do a post on the semaphore and start running. The second sender is then let in (because of the post) and it can get going and so on. This approach works very well if the semaphore has been manually deleted from /dev/shm/ or c:\temp\boost_interprocess\, but will not work if there is an old semaphore around. I can get around this on Windows by doing a named_semaphore::remove, since that will fail if a process has got it loaded. But this same code will not work on linux, since the semaphore will be unlinked and then all the processes will be able to delete the semaphore and will then be using different semaphores! I am used to semaphores working so that if it is opened when noone has it loaded it will be initialized to some known value, but this does not appear to be the case with Boost.Interprocess semaphores? Is there something obvious that I've missed, or some other way of accomplishing the same thing? Cheers Lars