At 08:24 PM 10/12/98 -0400, Tyler Close wrote:
>My concern is that you may have stretched this paradigm [only asynchrony
>between vats] beyond its natural bounds.
>From where does one get prior knowledge of the bounds of a paradigm? Only
by stretching a paradigm until it breaks (or at least shows stress) to we
find out what its bounds are. Microcosm was E's first big stretch, and it
held up better than could have been expected.
>Asynchronous communication does not make sense for communication
>between vats located on the same physical computer. This is bad since this
>type of communication will be more prevalent.
Argument by assertion?
>>And don't discount just how difficult a problem ...
>>... One of our mantras became "Threads Are Evil".
>
>This is like saying "Recursion is Evil" because some dopey C programmer
>will try to break out of the recursion by doing a goto to some other line
>in the program.
Or like saying that self-modifying code is evil, or that goto's are evil, or that pointer arithmetic is evil. Note that in a von Neumann machine, code is actually held in mutable memory, flow control actually happens with goto's, and object-state actually lives in arithmetically addressable memory. Useful and beautiful things have been done with all three that aren't possible under the corresponding three restrictions. Are we stretching something-or-other beyond natural bounds to impose these restrictions?
Our ability to get computers to do things is limited mostly by how much we can say before we've gotten hopelessly confused by what we've said. Sometimes we get more power by inventing new powerful primitives, but sometime we get more power from figuring out which powerful primitives to avoid. The key for the above three is that the primitives given up, though seductive on small examples, create a complexity/confusion burden that increase badly when applied over and over and over again in composition. E postulates this is true for conventional threading/locking as well. But we'll only know by seeing what we can create without them, and how well.
>When doing multithreaded programming, you have to establish a certain code
>of ethics that will not be broken. I agree that there are many unethical
>programmers out there; however, I have found that it is possible to embed
>this code of ethics within the way that the library is naturally used.
The fewer such codes a programmer need be simultaneously burdened with, and the less non-local information they must keep track of to preserve consistency, the better.
What is this "consistency under concurrency" problem anyway? Where is the difficulty? I used to buy the standard CS line that we should think in terms of preserving object invariants (predicates over the local heap-state). Though it's probably formally equivalent at some weird level, I find it easier to think about avoiding computing from no-longer-valid assumptions. For a bare start on some Hayekian ramblings on all this, see http://erights.org/doc/elib/elibmanual.pdf Chapter "Concurrency Control", Section "Safety: Preserving Consistency".
More, asynchronously, later, <- MarkM