Re: [boost] [boost thread rework] New version uploaded to Boost Vault

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2005-09-01 02:06:27

Matt Hurd schrieb:

>>I'd really like to know that the existing library is being actively
>>and conscientiously maintained before we move on to bigger and better
>>things.
>>    
>>
>
>Perhaps not too much to ask for...
>
>I tend to agree with David's sentiment.  I'd be happy to start a
>simplification and restructure of the basic primitives.  The code
>should be restructured into platform specific implementations, like
>boost has elsewhere (such as the atomic inc for shared_prt),  as the
>current code I find a little tricky to read.
>
>With such a restructure the various platforms could have different
>maintainers to eliminate a bit of the difficulty of trying to support
>such a cross platform library.
>
>  
>

This is the second time I see this happen :-(

Bill Kempf, the original author of the library silently disappeared.
The reason always was unclear to me. It looks to me as if he was
disappointed that the C++ comitee did not accept anything of the
threading work so far. Please correct me if this are wrong impressions.
At least I learned this from digging through the muddy waters of the
mailing list archive.

Next Michael Glassford appeared, trying hard to improve on the
library. I don't know what happened. I don't know whether he
underestimated the task or he is beeing teared apart by something
different. At a minimum I would like to hear what he has to say
about the new plans. (I also BCC this to him directly.)

In the end this all led to a major starvation on the threading issue.

Also there are some areas that cannot be addressed with library
code alone (I think): As Andrej Alexandrescu et. al. were
poining out some semantic changes to the compiler are in order
to provide a true multihreaded architecture. (Atomicity, memory model,...)

On the other side there is a need for multithreading that can do
with current compilers. (And the current library is doing quite well.)

>I could pull together a basic posix-based implementation which could
>be used on win32 with the posix32 lib as well, though a native win32
>should happen as most people would find the posix32 layer
>unacceptable.
>
I would rather like to see the current interface kept as much as possible.
Did anyone yet try to find out how deeply the boost::thread is currently
wired into the boost lib?
I think it would be a good staring point to find this out before any 
interface
changes are beeing introduced, or else we will end with the need to support
two possibly incompatible threading libraries.
And keeping the interfaces would not rise copyrigth issues would they?

>  Perhaps the current implementation can be refactored to
>do this, but starting from a clean slate so that the work can be
>licensed under the boost license might be best.
>  
>
Refactoring looks attractive to me, but keep the interfaces.

>Level 0 - basic atomic ops, fencing, thread, mutex (normal, recursive,
>rw), condition - to be replaced and updated with the work happening
>elsewhere by Lea, Boehm etal.  This should also replace the atomic ops
>used by shared_ptr over time.  Should be in a style that suits generic
>programming via a consistent interface which is currently lacking.
>
>Level 1 - futures, threadables, message queues, etc, primitives along
>the direction of Henney's work.
>
>Level 2 - Framework abstractions to architect single process,
>multi-process, multi-computer workflows.  Needs boost::net / comms to
>reach its potential.
>
>  
>
I am missing TLS from this list.

>Any thoughts?
>  
>
I like the idea of splitting the lib to maintainer/platform a lot. But 
we would need
to agree on a coordinated process for defining the interfaces. Any 
suggestions?

At the same time I again announce my willingness to volunteer for
the win32 part.
I already gained some insight when working on the TLS implementation for
windows. I also attempted a clean rewrite of TLS (using the same 
interfaces) for the
windows platform, that resulted in a aprox 4times speed improvement.
Unfortunately I never had a chance to discuss this on the list.

Then I suggested a so called thread alerter which can also solve most
of the practical thread cancellation issues. (It is not true 
cancellation though.)
Considering the constant requests for addition of thread cancellation,
surprisingly there was almost no feedback on this at all

Regards
Roland