If I[he] were king: A proposal for fixing the Java programming language's threading problems

[gordon_hutchison@xxxxxxxxxx]

To java-threads@xxxxxxxxx
An interesting article by Allen Holub with the above title appears here:

http://www-4.ibm.com/software/developer/library/j-king.html?dwzone=java

As someone who implements sysThreadCreate, sysMonitorEnter and most of the
other functions
these proposals would boil down to I find them very interesting.

Would their implementation be welcomed as a sensible evolutionary
improvement
or a missed opportunity for introducing more radical elements?

>From the commercial world's point of view my vision is constrained by the
importance
of reliability, speed and scalability of a particular JVM implementation
and the need
for a common standard - to prevent fragmentation of the Java market which
would
then be very much more vulnerable to spoiler initiatives like '.net'

However (and remembering the above), I cannot help thinking that having
humans manage concurrency
too much (especially in a world of weak consistency MP boxes, parallelising
JITs,
optimising C compilers that reorder statements, (explicit) parallelising
super scalar
processors etc etc) is akin to the time when humans wrote
code overlays before we had virtual memory subsystems.

Is the final goal not one where the amount of parallelism is left to the
system
and humans are left to specify as little (or as  much) as they want to .

If I have a code block like:

{
   x= 3;
   y = 4;
}

Then I might infer that both assignments run on the same thread, on the
same processor,
in a particular order and have even happened at all by the time the "}" is
reached.

Down at the bit level, all of these assumptions are getting harder to
support in modern systems,
(and a cause of defects on weakly consistent;/RMO machines)
so why are they so hard-wired into our favourite languages? Are we just
stuck in 'linear' mode
as Edward De Bono would say or is this a vital part of making a programming
language understandable?

Sure,some algorithms are most clearly represented as a stateful thread that
is manually
created and destroyed and given something to do (wait on a mutex, condition
or loop)
when we really don't want it to do anything.  It is just that I cannot help
feeling that I
would rather have the system deal with the actual thread physical threads
most of the time.

Does this lead us to the 'task' engine, munching through requests, such as
Allen proposes
or a more functional language (like Erlang?) or one based on a particular
process algebra (like Pict?)
or libraries like JCSP and CTJ?

I would be very interested in your thoughts regarding the longer term view.

PS. In this note my views are my own and  don't represent any IBM
position on Java threads or related areas.


Gordon Hutchison
IBM Java Technology Centre,
IBM Hursley, UK.
Notes:   Gordon Hutchison/UK/IBM
Internet: gordon_hutchison@xxxxxxxxxx
Phone: (+44)/(0) 1962 815646 (Internal IBMUK-245646)