[E-Lang] Re: Why Not Coroutines? (was: Deadlock-free [was what is good about E?])
Wed, 18 Jul 2001 20:10:15 -0700
That was a well-written and highly accurate summary of one of the three reasons
that pre-emptive multithreading is so abhorrent to me as a programmer.
The first reason, as you described, is that pre-emptive multithreading
prevents me, when reading a sequence of source code, from using valuable
assumptions about how all of the state remains unchanged during the execution
of this sequence except for changes caused by the code I am looking at.
The second reason is deadlock.
The third reason is that bugs caused by the first two reasons are almost always
non-reproduceable and rare, thus being much more destructive and time-consuming
than a reproduceable and frequent bug would be.
If I understand correctly, E's execution model completely solves all three of
So describing E as "deadlock free" may be describing only one of three valuable
improvements for the working programmer.
> When coding, I, and I believe most programmers, need a strong convention
> about what boundaries in a program represent places where they need to
> recheck assumption, because things can change since "they" last looked. (Or
> rather, when the narrative in their head about what the program is doing last
> looked.) Our naive intuitions from sequential programming are mostly
> inarticulate, but go something like:
> 1) On entry to a function/method, assume state invariants are intact, but
> within those constraints anything may have changed. [...]
> 2) From one instruction/expression/statement to the next, assume that the
> immediately accessible world is only affected in the ways I (this code)
> affects it.
> 3) Between a call and a return, assume that the callee only affects the world
> in way I can understand. (This is strengthened in a pointer-safe language,
> and especially in a capability language, in that we may have a principled
> basis for reasoning about the what state the callee may and may not affect.)
> Advocates of pre-emptive shared-memory multithreading would have us relearn
> #2 and #3. I say #2 is too valuable and relearning it is too hard, so forget it.
> Advocates of coroutines would let us keep #2, but have us relearn #3. We
> see by the hypothetical transformation, combined with a coroutine-based
> scheduler, that the programmer using such a hypothetical transformer is now
> writing source code that confuses #1 and #3. Put another way, since the
> transformer silently turns #3 into #1, on return from a call, we would now
> have to be as assumption-free about the current state as we normally are on
> entry to a method.
> Traditional pure event-loop languages (Actors...Toontalk) have not had
> call/return, but are faithful to intuitions #1 and #2.
> E is faithful to all three intuitions.