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

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

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.

Best,

Ion