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

Subject: Re: [boost] Request for interest in the new Synchro library
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-03-09 03:33:54

----- Original Message ----- 
From: "Dmitry Goncharov" <dgoncharov_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, March 04, 2009 3:03 PM
Subject: Re: [boost] Request for interest in the new Synchro library

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

I can use the sem_ family functions where available. But we need a implementation on the other platforms.

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

I was not aware Boost.Interprocess do that already. I will have a look.
   
> 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).
 
Thanks for the link.
Vicente