Re: [boost] Re: Not keen on Boost.Threads? [was: name of the "thread" type]

From: Ross Smith (ross.s_at_[hidden])
Date: 2001-07-01 23:32:27

Apologies for taking so long to get back to you on this; I've been a bit
busy. (I recently installed a multiple-boot system on my workstation,
with the result that I spent most of last week playing musical chairs
with various bits of hardware and software, trying to get Linux and
Windows to play nice together.)

williamkempf_at_[hidden] wrote:
> 
> --- In boost_at_y..., Ross Smith <ross.s_at_i...> wrote:
> 
> > It also seems to be following the pthreads architecture too closely
> for
> > my taste. It doesn't really "feel" like a designed-from-scratch C++
> > library to me -- more like a thin OO wrapper around the pthreads
> API,
> > and an attempt to emulate it on Windows. (I'm thinking in
> particular of
> > condition variables, a pthread-specific concept that I don't think
> > belongs in a generic threading library.)
> 
> This is ironic.  I'm the main developer on this (though I've gotten a
> lot of input from others) and I'm a Win32 programmer with little
> experience with pthreads.  The only thing in the library that is
> pthread-like instead of Win32-like is the condition variables, and
> this happens to be a major lacking in the Win32 API.  I don't know of
> any serious MT programmers on the Win32 platform that haven't rolled
> their own CV concepts because of this.  The CV concept is _required_
> to use a monitor pattern, which is one of the most flexible and easy
> to use synchronization concept in OO programs.

Probably part of the problem for me is that I've had to work out
techniques for cross-platform multithreading myself, with no contact
with anyone else working on the same sort of thing, so I've probably
reinvented several wheels and ended up with different concepts and
terminology. I have no idea what a "monitor pattern" is, for example.

I've always found condition variables very complicated and difficult to
understand. Whenever I use them I always have trouble working out how to
make them do what I want. I find the Windows equivalent, events, to be
much more intuitive and easier to follow.

> In fact, I'd expect more people to accuse the design of being too
> Win32 biased.  For instance, the design of the Semaphore includes a
> max setting and methods to increase the semaphore value by variable
> amounts instead of one at a time.  Another example is the design of
> the thread class itself, which allows for multiple join() calls and
> has no concept of detach().  I could continue with this list, but I
> think you get my point.

Well, no, not really. The whole "join()/detach()" concept is pthread
specific.

> > (When I have a bit more spare time, I'll polish up my own thread
> library
> > and post it somewhere for comparison.)
> 
> I'd be interested in seeing this, but it may be better for you to
> point out specific things in the current implementation you'd do
> different.

Looking back at the path the design has been taking recently, I suspect
we've diverged too far. I can't understand the liking so many people
have for the "thread_ref" concept. Non-copyable objects, with smart
pointers when necessary, are the standard C++ idiom for this sort of
thing; why treat threads differently? I'm afraid I Just Don't Get It.

Anyway, in case anybody's interested, the current state of my threads
library can be found at:
http://storm.net.nz/~ross/c++/rs_threads.tgz

I'll probably add a few more bits to it -- there's no semaphore class at
the moment, and I'm dithering over whether some sort of "synchronised
smart pointer" template would be a good idea.

(I've made one major change recently: prompted by this discussion, I
took a more careful look at my design, and (among several smaller
changes) decided that abandoning ("detaching" in pthreads jargon) a
thread was never a reasonable thing to do. The Thread class's destructor
now blocks instead of abandoning a still-running thread.)

-- 
Ross Smith <ross.s_at_[hidden]> The Internet Group, Auckland, New Zealand
========================================================================
"Unix has always lurked provocatively in the background of the operating
system wars, like the Russian Army."                  -- Neal Stephenson