Subject: Re: [boost] Request for interest in the new Synchro library
From: Dmitry Goncharov (dgoncharov_at_[hidden])
Date: 2009-03-04 09:03:45
> 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
> 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
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() 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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk