Re: [boost] Request for interest in the new Synchro library

Subject: Re: [boost] Request for interest in the new Synchro library
From: Dmitry Goncharov (dgoncharov_at_[hidden])
Date: 2009-03-04 09:03:45

vicente.botet wrote:
> You implementation has some deficiencies. It add another mutex to the semaphore.
Yes. I dont like it. A good implementation should be as efficient as 
posix's syscalls. Unfortunately, i can't figure out how to make one for 
unix.

>  My implementation do not add nothing more. Just controls that second posts are ignored as you have requested.
They are not just ignored, since if some thread has a mutex locked other 
threads that invoke post() are blocked. try_lock() lets other threads 
keep running.
In fact, sem.post() cannot block. Posting a semaphore is a non-blocking 
operation. It is even async-signal safe.
If semphore::post() locks a mutex it is no longer non-blocking. IMO, 
synchro::basic_semaphore::post() should not lock a mutex as well.
You could use a pipe to implement semaphore with non-blocking post(). 
Please, find a link to one implementation below.

>   
>> In one of the previous posts i described why a 
>> binary_semaphore::timed_wait() was superior in my case than 
>> condition_variable::timed_wait(). Using a condition variable defeats the 
>> purpose of a binary_semaphore (at least in my usage scenario).
>>     
>
> Well all depends, on how the Semaphore::timed_wait is implemented.
>
>   
Exactly. It should be just a call to sem_timedwait() on posix. Other 
implementations are possible. Anyway, on posix any proper implementation 
of semaphore::timed_wait() should be more efficient than 
condition_variable::timed_wait(), because 
condition_variable::timed_wait() has to lock a mutex in order to return.
>
> In my case it inherits from the basic_semaphore<>::timed_wait.
>
> So in both cases 
>
> yours::binary_semaphore<mine::basic_semaphore<multi_threaded_tag> > will even lock more than
>
> mine::basic_binary_semaphore<multi_threaded_tag> >
>
> Maybe your binary_semaphore class works better with Semaphore classes that do not use conditions. But do you have such a portable Semaphore class
No, i dont. I just used semaphore from boost::interprocess, since it is 
the only currently available in boost. The posix implementation of  
boost interprocess semaphore uses sem_timedwait().
>  If you have I'm interested also.
>
>   
You can find one unix implementation here 
http://www.kohala.com/start/unpv22e/unpv22e.tar.gz. This archive has an 
implementation of semaphore, not binary_semaphore.
In order to make binary_semaphore the size of the pipe has to be 
restricted to 1 byte. It is possible to restrict the size of a pipe on 
windows. I dont know how to restrict the size of a pipe on unix (besides 
recompiling the kernel).

BR, Dmitry