[boost] Re: Threads Rewrite?

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-27 13:55:13

Dayton wrote:
> 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?

[following paragraph re-ordered from end]

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

Actually, I think a good many of the issues you raise below were 
considered and the current design was consciously chosen, though not 
necessarily completely followed through on because the implementation 
was never completed. For instance:

> A complete re-write should not be necessary, 

As indicated in other posts, the re-write may be necessary not for 
technical but for licensing reasons.

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

There disadvantages to that approach, which have been detailed elsewhere 
(I believe in other postings in this mailing list, in 
comp.programming.threads, etc.). One disadvantage, for example, is that 
you you have to do a lot of extra work to create a new type of worker 
thread, while in the Boost.Threads approach there's only one type of 
thread class and you do a different type of work simply by writing a new 
thread function.

I've implemented threads the way you suggest before (more than once) and 
prefer the Boost.Threads approach, as I'm sure many (though not all) 
others do.

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

True, you could implement thread-specific variables as thread class 
members, but why would you want to? One immediately obvious disadvantage 
is that you would then need to modify the thread class whenever you 
needed to add, change, or remove a thread-specific global variable.

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

Certainly destructors can help with releasing or resources, but you 
would still need join or some other communication mechanism to reap the 
status and/or result of the thread. If you prefer another communication 
mechanism, you can use one by making the function you pass to the thread 
object call the mechanism before returning and making the creating 
thread not call join.

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

Mike