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
> > 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
> > 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
> stating these here again just for the record, not because I want to
> 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
> discussed earlier I missed it) I've never been able to see the
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk