"Jonathan Scott Duff" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> > If we could think about "threads" not in terms of forkyness, but simply
> > in terms of coroutines that can be called in parallel, it should be
> > possible to create an implementation of "threading" that had to do a
> > whole heck-of-a-lot less duplication of state, etc.
>
> See, this where I start to feel all Cozeny and wonder what the heck
> we're doing even thinking about how it's implemented.
I don't think this is an implementation issue: it is a user-level
distinction. Imagine the following algorithm
coro_sub_thingie tree_iter(FifoOutput $fifo: Tree $tree)
{
$fifo.cothread { tree_iter $tree.left };
$fifo.cothread { tree_iter $tree.right };
$fifo.emit $tree.node_value;
}
while < tree_iter $tree > { print }
(I've s/yield/emit/ to avoid mixing the control and data flow aspects)
This algorithm will work whether the "cothreads" are implemented as parallel
threads, or as coroutines. The difference is the scheduling policy. The
user-level difference is that one policy will produce a deterministic
ordering, whilst the other will be non-deterministic. We can provide a
common syntax to describe the dataflow constraints, and then find a way to
impose the sceduling policy that may, or may not, constrain the
control-flow.
My vision would be to enable concepts like threading and locking to go the
way of C<goto> -- it's there, but users typically use "structured" elements
that encapsulate the common patterns of use. Hoare's CSP is one such
abstraction; Shlaer-Mellor's wormhole abstraction is another. Other people
may prefer other abstractions -- but the safest code generally uses message
passing rather than shared variables (because messages don't require
user-level locking).
> What I want to
> know is how it looks from the user perspective. If, in order to
> understand threads, I have to first understand coroutines, I think
> that's a loss because it throws away (or at least morphs into an
> unrecognizable form) all of collect CS knowledge of what "threading"
> usually means. In other words, I think the idea of fork-like
> behaviour is important to threads.
Rather than understanding threads in terms of liberated coroutines, you
could instead try to understand coroutines in terms constrained threads ;-).
If a fork-like behavior is useful for threads, it may also be useful for
coroutines. But fork is a bit like goto -- its an unstructured primitive.
Dave.
