At 11:02 AM 10/12/98 -0700, you wrote:
>Remember that the motivation for E was to create not merely concurrent
>systems but distributed systems. Distributed systems have a degree of
>inherent, uncontrollable asynchrony that means atomicity is achievable
>only at the most extreme cost in performance and complexity. So we
>gave that up as a losing cause. Giving it up, however, means that
>deadlock something is we can now live happily without.
For transactions between vats located on physically distant computers, asynchronous communication has a pleasing symmetry with the reality of the underlying hardware. I can see how one could design long-distance transactions to take place in a single bulked-up send / receive pair.
My concern is that you may have stretched this paradigm beyond its natural bounds. 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.
>And don't discount just how difficult a problem creating deadlock free
>software is in a threaded environment. Ancedotally, the majority of
>the really nasty debugging problems we had in developing EC Habitats
>-- in particular, in developing the underpinnings of what is now the E
>runtime library itself -- were deadlock problems in those few areas
>where we couldn't avoid threading. (We couldn't avoid threading when
>building on top of Java libraries for, e.g., I/O, that were
>blocking). 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.
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.
>Note that one of the problems with deadlock bugs is way you are
>vulnerable to them even (or especially) when they are in other
>people's software. For example, we had to concoct some truly horrific
>workarounds to deal with the fact that the Javasoft JVM garbage
>collector and storage allocator can deadlock against each other (!).
Yes, well, I think that the way that the Java software libraries have been designed is tantamount to sabotage upon the entire software industry. I was unaware of the possibility of deadlock between the garbage collector and the storage allocator. This hurts.
>Creating reliable software is hard enough by itself.
It's pretty fun though isn't it?