Re: CSP and Isolates

[Doug Lea <dl@xxxxxxxxxxxxx>]

I'm about to leave for OOPSLA for a week so can't reply now to all
your notes, but here are some comments about the Isolate JSR (121).

> For some reason, Isolates do not
> support an Interrupt operation (which is safe for Threads) - is this
> an oversight (Doug)?  It would seem a reasonable thing a manager might
> want to do.

The best way to do this would be to have an "interruptAll" method:
interrupt all threads spawned in the isolate. There is no way to pass
the identity of a particular thread across an Isolate boundary.  Also,
in most cases, you'd rather cause a Runtime.exit of the Isolate.

JSR-121 may support various options along these lines. But it is more
likely that we will instead put in enough basic communication
mechanisms that people can establish event-handlers etc to get these
effect themselves.

It now appears that JSR-121 will support the simplest and most
practical (yes, these are usually contradictory in Java) mechanism
possible to provide basic communication among isolates.  Right now the
main contendors are 1-to-1 pipes (based on 1.4 java.nio pipes) and a
restricted form of 1-to-many Event-Channels (which may be needed
anyway to permit termination event signals and the like across
isolates, which are needed for management).  These relatively
low-level mechanisms could then be used as the "transport" for
structured communication like RMI or JCSP channels. Comments and
suggestions about other options from people on this list would be
welcome. (Especially practical ones! :-) I'll bring them to the
attention to other members of JSR-121 expert group.

We're trying to get preliminary spec out of private-to-expert-group
phase soon (december?) to allow somewhat wider viewing and comment.
Next phase at least allows viewing/discussion by all JCP members,
which is the best we can do under JCP rules.

> Observation: I have problems from Windows applications interfering with
> each other anyway. 

It shocks me that people so concerned about such issues would be using
an OS that is pretty much intractable wrt them. The situation should
be better at JVM level, in that different Isolates will be guaranteed
not to interfere with each other. On Unix/Linux/OS-X/etc that maintain
better inter-application separation, you'll get better
guarantees. Even here there are limits due to inescapable sharing of,
for example, TCP/IP ports. So denial of service attacks and the like
can still cause resource-based problems across threads, isolates, and
applications. This even crosses machine boundaries on LAN-cluster-OSes
and cluster-JVMs. (BTW, Cluster-JVMs will be made possible by
JSR-121.)

> Well, we had all this 17 years ago with the transputer

For now and the near future shared memory multiprocessing has won the
parallel architecture wars.  LAN-Clusters are a close second. But
even here, distributed shared memory (DSM)-based approaches seem to be
winning.  

There are probably too many reasons for this (including non-technical
ones) to draw any firm conclusions. But my feeling is that it is
mainly due to good performance up through maybe hundereds of CPUs
resulting from the opportunity (not necessity) to share data across
threads, despite the fact that exploiting this intrinsically generates
more complexity. Taming all this has turned into a big challenge for
all of us. 

-- 
Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA
dl@xxxxxxxxxxxxx 315-312-2688 FAX:315-312-5424 http://gee.cs.oswego.edu/