[E-Lang] Speaking of Community Process: Memory Model & Threads

[Dan Bornstein]

My understanding is that most of the problems happen when multiple threads
access the same memory at the same time[*]. Since all user code ends up
happening in a single thread in the current implementation(s), having user
code do something wrong isn't an issue. Whatever problems E has are
probably all about how E's TCB (which does rely on multiple threads)
intercommunicates.

That being said, the fact that a (relatively) small number of runs of
programs seem to work okay isn't a huge assurance that E doesn't hit the
weird cases at all, since this sort of problem doesn't reliably manifest
itself unless you work hard at getting it to. (See the example code linked
from the memory model discussion page.)

-dan

[*] Canonical example, observing that (i == k) but (j != k), where p and q
    are references to the same object, and some other thread modifies that
    object during the following:

    i = p.x;
    j = q.x;
    k = p.x;

Marc Stiegler writes:
>>Wow. Java's threading is way more broken than I thought! I just talked to
>>Dean, and it sounds like all E implementations to date may fall into some
>>of these problems on shared memory multiprocessor machines (SMPs), and
>>possibly even on uni-processor Solaris JDKs as well. E has never been
>>tested on SMPs, and should not be assumed to work there until further
>>notice. Unfortunately, we currently have to state the same caution for
>>Solaris.
>
>Unless they have changed something very recently, every E program I have run
>on Solaris jvms has run identically to the E program on Linux and Windows.
>Which is to say, among other things, that Solaris currently passes all our
>QA tests, for better or for worse. We should revisit this matter when
>version 10.0 of E is released.