Hello Folks
I think we still suffer from thinking too much about context, rather than
communication, and above-all commitment, ie protocol. Conventional OOP
confuses context with communication from the beginning, and thus, in my
view, stands no chance of expressing predictable concurrent behaviour. (I
have completely lost interest in Java.)
Deadlock-freedom demands a higher layer of protocol - eg to implement
some kind of client/server relation. Transmitting a channel will require
the recipient to continue honouring such protocol. It must therefore also
receive state information (history). This is where I begin to get stuck.
One has to show that the design rules for client-server deadlock-freedom
remain obeyed for _all possible_ configurations (client-server digraphs).
(Each connection can lie at any state.)
It's not too hard to see how one might express the ability of a process
to accept such "typed" (?) channels, though one does wonder whether the
extra language complexity is worth it, and whether the wonderful
simplicity and readability of occam might vanish.
Transmitting a process might mean sending the _ability_ to honour a
certain protocol. Things seem to get worse, as far as predictable
behaviour is concerned. Any CS digraph is now possible.
I sometimes wonder how any software ever works! ...or perhaps it just
seems to...
Ian
Dr. Ian Robert East School of Computing and Mathematical Sciences
ireast@xxxxxxxxxxxxx Oxford Brookes University
(44) 1865 483635 Oxford OX3 0BP
Consultation hours for 2000/2001 Term 2
Not yet assigned