E Priorities & Triage

[Mark S. Miller]

At 04:56 PM 4/18/99 , Tyler Close wrote:
>> 		Without this, our concurrency story is obviously
>> 		incomplete, but I'd love to hear
>>             arguments that we can
>> 		postpone it anyway.
>
>Sure, I'll make an argument.
>
>Nobody outside of research labs actually does concurrent
>computations. Some people use multithreading to split large
>programs into smaller pieces, but these pieces are typically
>executed on a single processor machine. E's support for
>asynchronous method dispatch similarly allows you to carve up a
>program into different pieces. It's enough. I'm even having a bit
>of trouble understanding what I'd use separate vats for if I've
>got asynchronous methods.

Given E's event-loop concurrency, the additional big benefits from multiple 
Vats all come down to further decoupling time:

1) Sometimes you just want to write an isolated piece of computation as a 
large stack-recursive thing, and you'd hate to have to break it up into 
separate events.  A good example is Alpha-Beta lookahead/pruning in board 
game players.  (MarcS feels tempted to rewrite his Othello player in E.)  
If you want to do some large recursive algorithm and be responsive to the 
user, your only choices would be: a) reify the stack as data, and break the 
algorithm into small events manually, b) spin off a separate jvm to get a 
separate vat, or c) spin off a separate vat in the same jvm.  #c would be 
the most pleasant.

2) The ability to kill a runaway computation.  Elmer desperately needs the 
equivalent of a Control-C (squiggle-dot for you Mac folk) so the user can 
recover if their expression doesn't terminate.  Right now Elmer is written 
in Java and runs outside the Vat, so we could do this anyway (and I will), 
but Elmer should be rewritten in E.  It should at least be possible to write 
Elmer in E.  With only one Vat, there's nowhen for Elmer to stand such 
that it can kill a runaway.

Returning to our Othello player, you'd like it to be able to analyze while 
waiting for the user to make his move.  Once the user make that move, you'd 
like to be able to kill that analysis (keeping its conclusions so far), 
since now you've got more information.  (However, if you broke it up into 
separate events manually (choice #a above), this would still be easy.)

3) Priorities.  Java lets you specify priorities for a Thread.  E uses one 
Thread per Vat, so E could use these priorities as well.  A plausible use is 
to have a high priority Vat that's mostly idle managing the user interface 
and giving quick graphical feedback, talking to a low priority Vat that's 
usually busy doing the real computation.

4) Guaranteeing progress under mutual suspicion.  When two mutually 
suspicious entities share a Vat, all the Vat's resources are treated as a 
commons.  If one of them soaks up all the CPU, the other never gets to run.  
Depending on a given jvm's guarantees about inter-Thread starvation, if these 
two computations are placed in different Vats, an infinite loop by one 
would not prevent the other from making progress.  Note that the Java and 
JVM spec themselves do not provide adequate guarantees to obtain this 
benefit.


In any case, all the above is devil's advocacy.  I actually agree with your 
point.  Unless someone wishes to argue this more, I'm now planning to 
postpone the Vat-spawning and manipulation API till after this pre-publicity 
phase.  And I'm really happy to be able to postpone this.  Thanks.


>In explaining the present E concurrency story, I'd focus on how
>asynchronous methods allow you to interleave separate "threads"
>(lines? what's the word I'm looking for?) of computation to
>achieve the same effect that multithreading provides (for single
>CPU machines).

I agree.  Perhaps "plans"?  See the "Safety" section of 
http://www.erights.org/elib/concurrency/index.html


>I'd put persistence way above multiple vats per JVM.

Agreed.


	Cheers,
	--MarkM