From: Douglas Gregor (gregod_at_[hidden])
Date: 2004-02-12 17:55:44
On Thursday 12 February 2004 05:28 pm, scott wrote:
> so, is there room for 2?
Sure. One "obvious" question is whether your threading library would need to
be completely separate, or whether it should be implemented as a layer on top
of something like the existing Threads library.
I personally don't care much for the "standard" way of writing multithreading
programs, because it quite error-prone. Other methods, like the one you
propose and others such as the Join calculus, are less error-prone and often
more expressive. But, operating systems and VMs provide "standard" threading
models, so something like Boost.Threads can be a good implementation base for
higher-level multithreading, distributed, and parallel programming styles.
> very briefly, the boost model treats threads as a resource (fair enough
> to :-) and submits code fragments for asynchronous execution. in the
> alternate model, threads come about as a consequence of instantiating
> final (a la java) objects. the distinguishing attribute being that threads
> run code that is "part of themselves" rather than code being submitted
> from "outside". execution of the code is initiated by sending of a
> message (within my vocabulary that is actually a signal). the message
> can contain arbitrary data.
This reminds me of the actor model of distributed computation. If you are
familiar with actors, could you briefly compare/contrast your approach
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk