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