Re: Threads docs updated in CVS

From: williamkempf_at_[hidden]
Date: 2001-08-08 09:19:28

--- In boost_at_y..., Ross Smith <ross.s_at_i...> wrote:
> williamkempf_at_h... wrote:
> > 
> > I still wish that you could formally discuss the various parts of 
the
> > design that you disagree with so that we can actually determine if
> > there's some design flaws in Boost.Threads.  I'd really like to 
know
> > precisely why Boost.Threads won't be any use to you, and if there
> > could be ways to make it useful to you.
> 
> We've been through this and got nowhere. My main objections -- and 
I'm
> stating these here again just for the record, not because I want to 
open
> the argument again -- are that it uses too much pthread-specific
> terminology (e.g. "join"), it uses condition variables instead of
> events, it allows threads to be abandoned (detached), and it allows
> cancellation. Oh, and (although I didn't bring this up before; if 
it was
> discussed earlier I missed it) I've never been able to see the 
point of
> thread specific storage.

OK, last time it degenerated into a flame war, so I bowed out.  Let's 
keep the flames out of this and maybe we can get somewhere.  You 
think that it's to pthread specific, but I totally disagree with 
you.  Regardless, however, even if it were 100% exactly like 
pthreads, in what way does this make the library unusable to you?

To directly address the points you have here:

* "Join" is just a name.  Windows threads have the same concept via 
WaitForSingleObject() and it's variants.

* Condition variables are superior to Win32 event objects because 
they produce code free from race conditions.  We gave you exact 
descriptions of why.

* Windows allow threads to be "abandoned" as well.  In fact, this is 
the default behavior of the MFC CWinThread concept and you have to 
work hard to be able to wait on such a thread.  There are very valid 
reasons to "abandon" threads, but if you don't care to do so, you're 
perfectly welcome not to.

* Boost.Threads currently does *NOT* provide cancellation, while 
Win32 threads provide broken cancellation in the form of 
termination.  There's a valid need for thread termination, so at some 
point Boost.Threads probably will include it, but only after we can 
find a truly safe (and portable) mechanism for this concept.

* Windows threads also provide for thread specific storage.  If you 
don't have a need for this, you don't have to use it, but it's 
inclusion can't be viewed as a reason why the library is "not usable" 
to you.  I could go into a lot of detail about why TLS is needed 
(there's a good example of it's use in the implementation of 
Boost.Threads), but there's no reason to.

What you've listed here are gripes about how the design differs from 
what you want only.  They don't illustrate what you'd do instead.  
More importantly, they don't illustrate a single way in which the 
library won't work for you.  If the library truly has flaws I want to 
know about them to fix them.  If it's simply that you prefer some 
other design that provides the exact same functionality, then it's 
not helpful for you to continually bring this up.

> I've given up on the whole CV-vs-event mess; to be perfectly honest,
> I've come to the conclusion that most people have been brainwashed 
by
> the "Unix is always right and Windows is always wrong" school of
> thought, and aren't prepared to discuss the matter rationally.

You're letting your own biases cloud things here (this is NOT meant 
to be derrogatory towards you and I don't want to let this degenerate 
into a flame war, so read on and try and keep an open mind).  I'm a 
Windows programmer with only passing knowledge of POSIX.  If I'm 
biased or bigotted it's solely towards Windows and not towards Unix.  
As the main developer of Boost.Threads my own biases towards the 
Windows form of thread support are usually self evident.  I simply 
don't believe that "Unix is always right and Windows is always 
wrong", and in fact often believe the opposite.  But I'm also not 
blind to the fact that MS didn't always do things right either.  If 
you can accept all of this as true then you have to really think 
carefully about my motivation for including CVs.  The motivation is 
simply because the CV concept is a more robust, and safer form of the 
event; one not prone to race conditions from improper use.  As a 
Windows developer I've had to debug many race conditions and 
deadlocks that were the direct result of improper use of event 
objects, so I've learned this lesson the hard way.  It's also 
important to realize that CVs are not the invention of Unix or POSIX, 
but are a direct implementation of the Monitor concept of Dijkstra, a 
noted expert in the field of MT synchronization.  This is not a 
Windows vs. Unix issue, and you should not view it as one.

Bill Kempf