Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at