Skip to content

Toggle service links

Home details downloads links contact
linking up analogue devices switches counting actors sequencing prioritising
Beyond a certain level of problem complexity, it becomes necessary to constrain the concurrent operations. In procedural control languages (e.g. RoboLab, MindScript, NQC) this is achieved by setting task priority levels or by creating an overriding subsumption architecture. In agent/actor languages (e.g. MultiLogo, actor-lab) task prioritisation is achieved by the ‘suppressive control of objects’, ie actors can send, and be sent, meta-commands that change their state. If the ‘Allow Sleep/Wake’ condition is checked then these additional commands are made available—

A SLEEP message will cause an actor/counting actor to become dormant, a condition in which they will only respond to a WAKE message. Whilst dormant, any delayed messages will not be sent. If the actor/counting actor receives a WAKE command, it becomes active again (but only on the next process cycle, ie aprox 0.05 sec later— NB the average user does NOT need to know this). A FORGET message deletes the stack of delayed messages. In the case of a counting actor, all three message stacks are deleted.

The underlying processing is of course not actually concurrent, but has been designed to appear so to users controlling slowly moving models. The underlying cycle time of the system is aprox 0.05 sec, and each actor is then processed in a random order. It is possible, but difficult, to achieve indeterministic results if messages are passed between actors with no buffering delay. The 0.1 sec delay was added to solve any problems. The minimum delay used in normal user programming is 1 sec, and so the ‘particles’ representing message flow are timed to take 0.9 sec. Each input (which may be a sensor plus a switch) takes 0.15 secs to process, hence unused inputs should be disabled. Checking the battery level imposes a minimal overhead on the system.

Turning on the ‘slow messages’ condition causes messages to be visible as a ‘ripple’ through the actors (see the cascade demos), but of course makes control of real world events problematic. This condition is useful in debugging some logical problems, particularly those concerned with event prioritising.