|
Boost : |
From: Nathan Myers (ncm_at_[hidden])
Date: 2000-08-01 20:36:18
On Tue, Aug 01, 2000 at 03:36:07PM -0700, Dietmar Kuehl wrote:
> > There's a lot of interest in a good C++ thread library ...
> > ...
> > There's also a few "utility" objects that should be discussed for
> > inclusion in a threading library, such as shared memory, atomic
> > integers (integers with atomic mathematical operations) and thread
> > local storage, but for now it seems safe to me to leave them out.
>
> Taking the view of a library implementor I don't care at all about a
> thread class. ...
> 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.
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.
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.
Nathan Myers
ncm at cantrip dot org
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk