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

Subject: Re: [boost] [Interprocess::Semaphore] Deadlock on more producers - one consumer problem
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2009-06-21 22:43:56

On Sun, Jun 21, 2009 at 3:15 PM, James
Mansion<james_at_[hidden]> 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.
>  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.

Not sure what a khazi is :)  But regardless, I also feel like
modelling it after posix semaphores is a bit contrary to how other
libraries in boost work, or how boost libraries are supposed to work
in general (correct me if I'm wrong).  It seems to me like you should
be starting with requirements, and molding the o/s primitives to fit
the requirements.  Not molding the requirements to fit specific o/s
primitives.

For example, does anyone actually care that specifically that a
semaphore is in shared memory or a memory mapped file?  Or do they
just care that it can be accessed from multiple processes?  Ok fine,
before you shoot me, I'm sure that some people actually do want it to
be in a specific type of memory for whatever reason.  But regardless,
both o/s'es provide native support for semaphores that can be used
from multiple processes.  It seems like the interface should be
designed simply to distinguish whether or not it can be used in
multiple processes, and make the internals hide the rest.

There may be situations where you really want some o/s specific
behavior, but that's what an interprocess::posix namespace could be
used for.  Like in boost::asio I can use
boost::asio::windows::overlapped_ptr