Joshua Gargus wrote:
> Thanks for this interesting list of your relevant work.  I look  
> forward to any other thoughts that you could add to this thread, in  
> particular to provide a reality-check where your real-world  
> experience disagrees with my theoretical understanding :-)

Sadly, my practical experience is far more limited than it should be,
given all the years I have spent on this, since often a project would be
abandoned after only preliminary results in favor of a "much better"
one.

One thing that I haven't tried yet is making messages to futures return
new futures instead of blocking (which I understood from this dicussion
to be the E way). I had thought about it but imagined it might lead to
ever growing graphs of pending messages with no actual work being done.
I see now that in practice the overhead might be comparable to what my
deadlock detector had. This would probably also make my "tail send"
optimization mostly useless, which is a good thing.

In all my projects I took a very conservative path regarding blocks: I
simply defined "." as a kind of barrier where all previous instructions
must finish before any of the following instructions can be started.
Since I was getting a lot of parallelism even with this I didn't worry
too much about it and this allowed code like this to work just fine:

| a |
a := 1.
1 to: 20 do: [ :i | a := a + i ].
a := a - 1.
1 to: 20 do: [ :x | a := a - x ].
^ a

Having "." as a barrier is unecessary in the code below, but at least
the results will be correct even if at a much reduced performance:

| a b |
a := (1 to: 20) collect: [ :i | i * i ].
b := (1 to: 20) collect: [ :x | x + 7 ].
^ a + b

It isn't very hard for the compiler to know which is the case for each
example.

-- Jecel