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-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:
>>
>> 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);

http://www.opengroup.org/onlinepubs/007908775/xsh/sem_init.html

Best,

Ion