Boost logo

Boost :

From: Dietmar Kuehl (dietmar_kuehl_at_[hidden])
Date: 2000-08-01 17:36:07


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

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.

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

This is, of course, just my opinion. Maybe threading should be a topic
for the Boost meeting in October. It would be nice if we had one or
even better several proposals how to address this on the table. We
should then be able to at least determine a direction, pulling a vote
to determine whether there is support for this. My personal feeling is
that the group as a whole can provide input but "design by committee"
does not bring things really far. Thus, we really need proposals how to
address this, discuss and refine these probosals and finally have an


Do You Yahoo!?
Kick off your party with Yahoo! Invites.

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