Re: [boost] Re: Threads: what I wrote...

From: Alan Griffiths (boost_at_[hidden])
Date: 2000-08-09 15:50:54

In message <Es0InEAs7Wk5Ew$b_at_[hidden]>, Kevlin Henney
<kevlin_at_[hidden]> writes
...
> I
>would have thought (and it is certainly what I now practice) that the
>more appealing/natural approach would be from a generic programming
>perspective.
>
>In other words, initially drop all the talk of _a_ thread class to the
>requirements on Thread (as concept). 

This is certainly an approach that appeals to me - especially as I hope
to learn something from it.  (My understanding of MT is weak.  I can
write non-production MT code that appears to work reliably, but haven't
developed the strategies to write code that obviously has no errors.)

...
>I personally feel that an STL-like approach will lead to a clear and
>loosely coupled set of interfaces, and is the better way to go these
>days. It also unasks a number of questions that have been floating
>around, such as process vs thread locks (either can be handled), should
>unlock be public (yes, because these are primitives and the locker
>classes are there to do the right resource management thing), and so on.

These questions need unasking - they are important, but we need to map
things out at a higher level of abstraction.

...
>I'm happy to work out a strawman doc based on this idea and building on
>Dietmar's definition's doc, if anyone's interested.

I'm interested, and willing to review it - but not as a domain expert
(see disclaimer above).

One thing that I think we are still missing are usage scenario (or
'concurrency idioms' as Dietmar refers to them).  In their absence it
will be hard to be confident of any design process.
-- 
Alan Griffiths  (alan_at_[hidden])  http://www.octopull.demon.co.uk/
ACCU Chairman   (chair_at_[hidden])             http://www.accu.org/