Re: [boost] Future of threads (III)

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
> only
> 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 
against them?

        Doug