[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Lamport and toy languages
Dear All,
This has been a most interesting discussion. On a practical thought
though, Peter has allowed us to use shared channels *easily* with the
later releases of KROC. These have proved invaluable in building io
systems where many processes wish to share access to an io resource. As
usual the main contention in most languages is how they deal with io as
commented on by Adrain in his previous comment. The beauty of the shared
channel is that yes it does have extra semantic complexity concerning the
ordering of processes accessing the shared resource BUT once the process
has gained access then we can reason about the interaction in exactly the
same way as we can about any other communication. That is we do not have
to anything special. The problem with the KROC implementation versus the
occam3 implementation is that you have to program the semaphore that
controls the shared resource yourself AND this is a source of error!
I guess what I am saying re-inforces all the comments that have been made
from an engineering point of view. Could I also re-iterate a point that
Peter made in a response to Paul about the writing of an occam compiler
in occam as a collection of processes.
I have recently being doing some work on modelling the movement of
pedestrians in congested urban areas. This of course is highly parallel
as each person in the simulation is naturally a separate process. By
modelling it in parallel we get away from the standard simulation
technique of let everything run for a fixed timestep and see where
everyone has got to. The modelling becomes a lot more natural with
regard the real situation. It gets even more fun when you permit
interactions between vehicles and pedestrians both of which operate in
parallel separately and with each other, ignoring jay-walkers, the
interaction is at pedestrian crossing places. Building this as a set of
objects or in a traditional programming language would be impossible from
the point of view of subsequent reasoning about the operation of the system.
Just adding my threepeneth to the the case for occam
Jon
Professor JM Kerridge tel +(0) 131 455 4395
Department of Computer Studies fax +(0) 131 455 4552
Napier University email j.kerridge@xxxxxxxxxxxxxxxx
219 Colinton Road
Edinburgh
EH14 1DJ