Re: Threads

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 
against
>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 
library.

>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 
two
>libraries to be used in a project are written with two different 
thread
>libraries: They simply won't work together. Thus, there can only be 
one
>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 
possible.

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 
architecture
>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, 
pthreads)).
>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 
latest
>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