[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


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
EH14 1DJ