Subject: Re: [boost] [Interprocess::Semaphore] Deadlock on more producers - one consumer problem
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2009-06-20 18:29:34
Zachary Turner wrote:
> 2009/6/20 Ion Gaztañaga <igaztanaga_at_[hidden]>:
>> Zachary Turner wrote:
>>> Sorry for jumping into the middle of this. But shouldn't it only
>>> notify_one() if count is greater than or equal to 0? Not
>>> unconditionally. It's possible to initialize the semaphore with a
>>> negative count, and in that case a call to wait() should not unblock
>>> until the semaphore is 0 or higher.
>> Ummm... Interprocess models POSIX primitives and I see that
>> #include <semaphore.h>
>> int sem_init(sem_t *sem, int pshared, unsigned int value);
>> semaphore value should be always positive, something that does not happen in
>> interprocess_semaphore(int initialCount);
>> So I think I should change interprocess constructor to an unsigned int.
> That works too :) Just out of curiosity why doesn't windows backend
> just use built-in windows api functions for manipulating semaphores?
> CreateSemaphore, etc? I haven't done any performance benchmarks
> myself, but it seems like using native system calls would be faster
> and more scalable.
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);
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk