[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
> 2. should we be looking to develop languages whose syntax/semantics do
> not allow the writing of programs that deadlock?
>In a sense, (2) was what the graphical occam Design Tool (oDT) was trying
>to do. That was a graphical language for designing process networks which
>understood certain design patterns (client-server, I/O-PAR and hybrids of
>these) for which we had formal proofs that the resulting designs were free
>from deadlock, livelock and process starvation. occam template codes were
>automatically generated from the designs. The problem was that the design
>patterns it knew about were not complete - there were some designs that
>were safe, but which neither wanted nor required the known patterns.
>In those cases, oDT allowed the designer not to specify to what pattern
>he/she was designing and turned off the checks.
The same could be said for any high-level language surely. There are many
sensible (correct?) programs one could compose in assembly language which
cannot be expressed in such a language. But we accept the loss of these
in return for security. (Many real (ie commercial) packages make
extensive use of assembly language components to circumvent compiler
checks that would reject their methods.)
I for one believe a language in which deadlock-free programs can be
written would be well worthwhile, even given the loss of expression that
results from the constraints imposed by known effective design rules.
No such thing as a free lunch...
PS Given that industry did not eventually "buy" occam, I very much doubt
if such progress would meet with anyones sheckles. How to "sell" better
software tools is another issue altogether. Back to my C programming...
Dr. Ian Robert East School of Computing and Mathematical Sciences
ireast@xxxxxxxxxxxxx Oxford Brookes University
(44) 1865 483635 Oxford OX3 0BP
"You can evolve what you could never design."
Consultation hours for 1999/2000 Term 2