|
|
Threads-Devel : |
From: David Abrahams (dave_at_[hidden])
Date: 2006-03-12 13:32:25
Roland Schwarz <roland.schwarz_at_[hidden]> writes:
>>Fantastic work, Anthony! This is really encouraging; we could be
>>free of the old license code and crufty implementation by 1.35!
>>
>>
> Just wondering: by "crufty" do you mean Terenkovs algorithm?
I think you mean "Terekhov?"
No, I mean the messy code where implementations for all platforms are
entangled in the same source files.
> (Besides I do not know exactly what crufty stands for, it is not in
> my dictionary. Something like old, superfluous?)
http://en.wikipedia.org/wiki/Crufty
> I thought we don't want the list implementation beacuse it will
> interfere with the system scheduler doesn't it? (I think I was suggesting
> this some time before, but from discussions I had to learn that we
> shouldn't use it. Don't remember every detail at the moment.)
> I didn't yet have time to study it thouroughly, but is the algorithm
> also free from the "overly strict locking" problem?
>
> I can remember a lot of past discussions about the best algorithm
> for condition variables on windows, and as far as I remeber there
> was agreement on Terenkovs algorithm wasn't it?
I don't know; if Anthony has discarded the work of A. Terekhov, I
would be very concerned. If nothing else, that guy knows his
threading.
> Also it is proven to work well and also is the basis of windows
> pthreads. So why should we go for something different (yet
> unreviewed) now?
>
> Please don't get me wrong, but I was thinking we are about to
> rewrite the library and aren't going to change it's design for the
> moment?
Design is a very broad term. We're not changing the API for the
moment. Implementation should change in a few trivial ways at least.
-- Dave Abrahams Boost Consulting www.boost-consulting.com