----- Original Message ----- From: "Dmitry Goncharov" <dgoncharov@unison.com> To: <boost@lists.boost.org> Sent: Wednesday, March 04, 2009 3:03 PM Subject: Re: [boost] Request for interest in the new Synchro library
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
vicente.botet wrote: 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