=============== clot-demo-8.occ =============== This is a new implementation of the "bump-and-stick" clotting system, based on the (Schnieder et al.) CSP design in the file: clump1d2d3dtock-2005-12-06.fdr2 This design is written up in the paper: "Communicating Complex Processes", Welch/Barnes/Polack, ICECCS 2006, Stanford, University, August, 2006. and (partly) described in: phw-08-02-2006.ppt It runs a *busy* cellular automaton representing the space in which the clots (or activated platelets) exist. The presence of activated platelets is refelected by the state of the cell processes. Movement and clot formation depends on external choice between multiway event synchronisations. A fast implementation for the latter is described in the above paper, with a formal presentation in: mm-sync-oracle-0-1-05-12-13.csp It runs the same user controls and visualisation as "clot-demo-6.7", reporting timing using the same measures (cycle times per cell). An extra control is provided to determine the probability of clot movement (which is flat in this version, independent of clot size). The information in this model does not have access to clot sizes. Without this extra control, the (lazy) resolution of multiway choice used by the implementation means that clots would always move - and never, therefore, bump. See the paper for further explanation. Initially, the control is set to give 100% probability of movement. For clots to develop, this should be lowered. Generation of blood clots at the start of the blood vessel is automated. There is a user-defined probability of clot generation. Initially, this probability is zero. Such automatically generated blood clots are always of size 1. Individual blood clots (of sizes 1-9) may also be injected at any time. The blood vessel is rendered every 'n' cycles, where 'n' is user defined (between 1 and 65536 in powers of 2). Initially, rendering takes place every cycle. Text rendering takes a significant time. Reducing the rendering frequency exposes the true speed of the model. The whole system may be user-frozen at any time. The system may be user-terminated at any time. All processes terminate cleanly -- there is no "system.exit(0)" cheating! The display also shows the current cycle count and the average cell cycle time (in nanoseconds) over the previous 1024 cycles. These times include the cost of display rendering. To factor this out, increase the cycle interval between frames (see below) to at least 4096. In "clot-demo-6", cell cycle times depend on the "busyness" of the system. Very long blood clots are expensive in this version of the system (as its size is computed each cycle by sending a signal along its whole length). In "clot-demo-7", cell cycle times depend on the number of clots in the system (and how often they bump!). It is independent of the size of the clots and the number of cells (if we ignore visualisation costs). However, more cells does imply the possibility of more clots. In this version, "clot-demo-8", cell cycle times also depend on the "busyness" of the system. There is no particular penalty for very large clots. The controls are by keyboard character input: G - increase the probability of clot generation (by 1/256) g - decrease the probability of clot generation (by 1/256) M - increase the probability of clot movement (by 1/256) m - decrease the probability of clot movement (by 1/256) D - increase the cycle interval between frames (by doubling) d - decrease the cycle interval between frames (by halving) 1 - inject a clot of size 1 2 - inject a clot of size 2 . . 9 - inject a clot of size 9 F/f - freeze the system (any character resumes) Q/q - quit the system This version of the program has a blood vessel of (60 x 30) 1800 cells. The screen window needs to be at least 80 across by 40 down for best viewing. If you freeze the system and then resume it, the timing becomes invalid for the cell cycle and it is not shown. Cell cycle times are only shown for uninterrupted sequences of 512 cycles. Note: version "clot-demo-6" uses the BARRIER SYNC mechanism introduced (by Fred Barnes) into KRoC occam version 1.3.4-pre6. That automates the registration of processes into BARRIERs (CSP mulitway events), making it impossible for an unregistered process to SYNChronise on the BARRIER. Such a mistake was possible with the previous implementation of barriers as a user-defined type. The new mechanism is also faster (approximately 18 nanoseconds per SYNC per process, measured on the Dell 3.2 GHz. P4 TUNA nodes). Note: version "clot-demo-7" uses the MOBILE BARRIERs introduced (by Fred) into KRoC occam version 1.3.4-pre8. Mobile barriers are needed to allow them to be passed to FORKed processes, whose parameters must be passed by communication. Note: sorry, these BARRIERs may only be used for committed SYNChronisation. An extension allowing them to be used as ALT (CSP choice) guards is being considered. This version, "clot-demo-8", is based upon "ALTable BARRIERs". These are only just being considered for inclusion in occam-pi. Meanwhile, this system uses the application-level mechanisms (described in the paper) to build something executable. Compilation: kroc -c mm-sync-oracle.occ kroc rand-clot-demo-8.occ mm-sync-oracle.o -lcourse Peter Welch. (10th. August, 2006)