Re: [boost] Re: no semaphores in boost::thread

From: Maciej Sobczak (maciej_at_[hidden])
Date: 2003-06-07 09:10:26

Hi,

Alexander Terekhov wrote:

> and, believe 
> me, you'll realize rather quickly that monitors based on MESA/POSIX condvars 
> are much, much better than anything you could do with semas

I understand your point.
I have been using Windows API *before* I got a chance to read 
"Programming with POSIX Threads" by David R. Butenhof (excellent book, 
BTW) and maybe my attitude derives from this background.

I understand your response to Stefan Seefeld and I see your point that 
semas do not buy what they should buy and at the same time we have to 
pay for something that we do not really need.

However.

Some time ago I wanted to write a *portable* code (Windows included in 
the list of platforms), with queues between threads and so on. It was 
easier for me to write my own portable sema (and later use it in the 
high-level code) than to write portable condvar. Lurking into 
comp.programming.threads convinces me that it was a good decision, 
because from what I see there, implementing condvar for Windows is far 
from being straightforward. I believe that by going the easier way, I 
won the chance to have fewer bugs.
Note that I did not want to depend on any third-party threading library 
(like Cygwin) at that time.

Now, discussing Boost, the situation is different -- when writing *new* 
code, I would take your arguments into account and probably never missed 
semas. The problem is that there is existing codebase (also in terms of 
algorithms, not only as a plain code) depending on semas and this 
existing stuff cannot be flushed just because it is based on "incorrect" 
synchronization primitives.

What about providing both (condvars and semas), but with documenting 
known pros and cons?

> http://terekhov.de/downey03semaphores.pdf

Thanks for the link.

-- 
Maciej Sobczak
http://www.maciejsobczak.com/
Distributed programming lib for C, C++, Python & Tcl:
http://www.maciejsobczak.com/prog/yami/