From: Dayton (mvglen04-cnews_at_[hidden])
Date: 2004-07-27 03:04:32
> However it would be too bad if we needed a _complete_ rewrite of
> the threading library. Could anyone please drop me some lines
> why this should be necessary at all?
A complete re-write should not be necessary, but the current model of
associating a single method with a thread could be implemented as a
specialization of a more object-oriented approach of modelling a thread
as a class instance.
Another advantage of modelling a thread as instance of a class rather
than just a function is that you may elect to implement thread-specific
variables as thread class members. This works nicely if you enforce a
design rule of a single thread per instance of the Thread class. Some
of the things you must do in POSIX style C thread programming, or in the
Windows API for thread programming just aren't necessary when using C++
in an object-oriented fashion.
C++ provides some natural protections when using threads. For example,
POSIX threads must be join'ed to reap the status of the thread and
release the thread stack and other resources associated with the thread.
C++ destructors come to the rescue here.
Another issue to address is the different abstractions that the
different operating systems use. For example, Windows allows a thread
to be created in a suspended state -- but emulating suspended initial
state is fairly easy to implement in POSIX threads. I wouldn't, though,
want to saddle non-Windows programmers with an emulation they don't need
nor desire. This suggests a low-level Thread class that is almost a
lowest common denominator on all platforms, with child classes that
model the extensions of the various platforms. The extensions are
implemented natively on the platforms that offer it, and emulated on
those that don't.
I'd like to see the synchronization objects separated into their own
portion of the threads library because some synchronization methods
require non-C++ standard implementations -- the volatile keyword isn't
the same thing as a LOCK prefix or direct assembly language access to
CAS instructions. Work in this area should be directed at suggested
changes in the C++ standard to address multiprocessor problems.
I mention these issues because I don't think the original Boost threads
library fully considered them. I'd like to see these issues and others
discussed before we jump in and implement.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk