[boost] Re: Threads Rewrite?

From: Dayton (mvglen04-cnews_at_[hidden])
Date: 2004-07-27 03:04:32

Roland wrote:
> 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.

Glen