Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-02 10:21:43

There've been a lot of responses (which is good) to my posting.
Instead of addressing each in a seperate post I'm going to address
the pertinent (to me) parts from each in a single post.

>From: Dietmar Kuehl <dietmar_kuehl_at_y...>
>Date: Tue Aug 1, 2000 10:36pm

>Taking the view of a library implementor I don't care at all about a
>thread class. What I would like to have, though, is access to thread
>locale storage and a fast approach to protect shared resources
>simultaneous access. The latter might be achieved with a mutex but
>there may be better approaches, too.

I can understand your point of view here, but I don't agree.
Providing only a partial solution is worse than providing no
solution, IMHO. I agree that for library implementers such as
yourself you have no need for creating threads (today, any way) but
are still concerned with protecting your code from threads the user
may create. But to provide classes solely for protecting against
threads while not providing threads seems backwards. Especially if
the synchronization objects, et. al. were exposed publicly by the

>Although I agree that a threads library would be great, I still think
>we should determine what we want the library to do! This in turn asks
>for some form of definition what we mean with thread safety and what
>idioms and rules are appropriate to guarantee this thread safety.

I agree with this sentiment. However, you have to start somewhere,
which is why I suggest starting with the small set of primitives I
mentioned. It seems to me that these would form the basis for any
other designs or concepts that could be devised in our pursuit of
a "standard thread library". Especially if we're limiting ourselves
to a library (as seems appropriate both for Boost and for the C++
language) and not a language change.

>The importance to do this right is simply that it does not help if
>libraries to be used in a project are written with two different
>libraries: They simply won't work together. Thus, there can only be
>and this has to be just about right. Having something too slow, too
>inconvenient, too complex, not covering everything, etc. will be a
>killer argument. Basing a library on this stuff would make things
>really bad...

The goal of Boost is to define libraries that will prove to
be "existing practice" that can be the basis for further advances in
the standard. Given this, it doesn't seem unreasonable to assume
that only one thread library will be used... the one we devise.
Mixing thread libraries will simply result in undefined behavior.
Not ideal, but honestly, it's the best we can hope for even with a
language change, let alone a library. Of course the need to
be "simple yet complete" is a given, but we've got to start somewhere.


>From: Nathan Myers <ncm_at_s...>
>Date: Wed Aug 2, 2000 1:37am

>Trying to define a "threads library" could easily turn in to a black
>hole, or a tar baby. Fortunately, Dietmar has shown us the way out.
>We don't need or want a "threads library". It wouldn't be portable
>anyhow, or would require so many compromises that it wouldn't be
>useful for real programs. What we need is just need the parts that
>are needed so that a portable library can be written that will work
>in a threaded program. This probably means a "mutex" type, and maybe
>(a couple of) read-write locks. It might have atomic-increment and
>atomic-swap-pointer primitives.

A mutex is going to be no more portable than a "threads library".
The pthreads standard has already proven that portable threads are

Yes, a thread library will be difficult to define and full of
pitfalls, but I don't think this is enough reason to exclude even the
attempt. Regardless, I still think it's a waste of time to go only
half way, as suggested.

>It might have lots of stuff, but most importantly it should lack
>any kind of thread_create() function, and anything useful only if
>you have it. The problem suddenly gets much smaller and easier
>to agree on, yet still enormously useful. Next year the bigger
>issues will still be there, but you'll have this library interface
>to build on.

The thread creation is really not that big of a tarball. In fact,
its the easiest of the concepts to implement, though the design needs
some careful thought. If the library ever does make it into the
standard it might be a difficult one for those implementations on a
platform that doesn't support threads at all, but it's still doable.


>From: Joe Gottman <joegottman_at_w...>
>Date: Wed Aug 2, 2000 0:34am

>Since threads, mutexes, etc. are very dependent on the local
>for their implementation, I think it would be a good idea to define
a basic,
>minimal interface for each, similar to the iterator interface used
in the
>STL. This would allow users to write portable template classes and
>functions parameterized on the thread, lock or whatever. For
instance, a
>thread safe Singleton template would be extremely useful.

Not a minimal interface, or the library won't be used, but a simple
interface. There are some concepts supported by some thread
libraries that may not be needed or desired for a portable thread
library. As for singleton... this isn't really a pattern suited to a
reusable template/base class design. Many attempts have been made to
do so, and IMHO all have failed. If you need a signleton you wind up
coding a singleton from scratch. The best we can hope for is that
the coding is intuitive and simple using our thread primitives.


>From: Michael H. Cox <mhcox_at_a...>
>Date: Wed Aug 2, 2000 1:40am

>If you're going to write a thread library, you might want to look at
how the
>ACE library does it (they support Win32 and UNIX (I think,
>We're using RW's Threads.h++ at work which they acknowledge was
based on a
>lot of ideas from ACE. It would be nice to have a thread library
that was
>more standards based than Threads.h++ and took more advantage of the
>C++ features.

I'm familiar with ACE. In fact, Mr. Schmidts (sp?) implementation of
conditions for Win32 is about the only useable implementation that
I'm aware of. ACE is a good source for ideas and issues to learn
from, but I think we should try to keep other thread libraries at the
very back of our thoughts here, lest they lead to design decisions by
precedent that may not be the best approach to the problem.


From: Jon Jagger <jon.jagger_at_q...>
Date: Wed Aug 2, 2000 6:55am

>I think it's easy to forget that read/write locks
>(for example) are easy for you to build from other
>primitives because you have experience. Many others
>would find it very difficult, which in my book is a
>strong argument for including them in the library.

I agree to some extent. However, I still think they need to be left
out, at least initially. Read/write locks can often lead to
inneficiencies when used as a generic replacement for full mutexes
(or is that muti?), as is the initial reaction to new programmers
that read about how they can be more efficient when there's a lot of
threads doing reads. I'm not suggesting we eliminate them entirely,
only that we eliminate them from initial discussion to help narrow
the problem domain.

>Lastly, genuine examples of using primitives to
>build higher level classes is a good way to
>test the design and usability of the primitives.

Very true, but we're not to that point yet. I use the same logic
when eliminating TLS from the discussion, since it can be simply
implemented by the primitives in my short list.

William Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at