Boost logo

Boost :

Subject: Re: [boost] [Interprocess::Semaphore] Deadlock on more producers - one consumer problem
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2009-06-22 16:08:05

James Mansion wrote:
> 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.

That would be incredibly slow. We would need to maintain a per-process
DB for name-mapping for each use. I think it's prohibitively expensive
when comparing to a few atomic operations.

> 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.

Which interface do you consider adequate for portability?

> 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?

Of course. Everything you map in a file ends in the file, if you write a
wrong data, it's your problem. This might unacceptable for some, but it
has some pretty good uses. For named resources (sem_open...) Unix
resources have kernel lifetime and they need to be unlinked, just like
files. This has some good uses cases but also problems and I'm open to

Achieving windows lifetime (reference counted) semantics is really
impossible in the presence (unless you develop a server ipc process like
wine) of process crashes is and that was a widespread complain in the
pre-accepted Interprocess library.



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