Re: [boost] [Interprocess::Semaphore] Deadlock on more producers - one consumer problem

Subject: Re: [boost] [Interprocess::Semaphore] Deadlock on more producers - one consumer problem
From: James Mansion (james_at_[hidden])
Date: 2009-06-21 16:15:32

Ion Gaztañaga wrote:
> Because that semaphore couldn't be placed in shared memory and 
> memory-mapped files, like its POSIX equivalent with pshared set to true:
>
> int sem_init(sem_t *sem, int pshared, unsigned int value);
>
That's not strictly true.  Put an unique name in shared memory, and do 
something to
cache the handle in accessing processes or the cost *will* suck.  
Unfortunately just
basing things on POSIX is a pretty bad design decision if you want 
portability - if
you manage it as 'a shared thing' and handles then its easier to 
implement with either,
though POSIX is still generally crappy because its hard to avoid races 
to initialise
the shared thing, and because its so badly defined what you can put it in.

POSIX shared memory?
SysV shared memory?
Memory mapped file?
memory mapped /dev/null?

For a memory mapped file, does the semaphore state persist if the file 
is closed
by all processes?  What about closed by all processes, and the system is 
rebooted?

Its a khazi, it really is.

James