Manifold Lab 3

1. ManifoldLab 3 Primitive operations, Streams, Events, A complete example

2. Summary • Streams (behavior, types) • Events (order, priority) • Primitive operations • Port conditions • The water installation example

3. Streams • Streams act as an infinite FIFO buffer • They have two identifiable ends: a source and a sink • They connect a source port to a sink port and perform the transfer of units between the two Stream behavior • As long as a stream is connected to a source port, it waits for a unit to pass through the port. As soon as this happens it copies the unit in its internal FIFO queue. A unit that is copied to all streams connected to a port is then lost. • As long as a stream is connected to a sink port, it delivers units from its own internal FIFO queue to the port. Units delivered to a sink port are removed from the FIFO queue of the stream. If more than one stream is connected to a sink port, they deliver their units to the port in a non-deterministic order.

4. Streams (2) Stream types • The connection between each end of a stream and the port it is connected to can have one of the two attributes: break or keep. • A break-type connection means that it breaks as soon as the stream realizes that the connection at its opposite end is broken. • A keep-type connection means that it does not break just because the connection at the opposite end of the stream is broken. • The combination of break and keep attributes for the two sides of a stream result in four primary types of streams: BB, BK, KB, and KK. • An additional attribute can be defined for BK and KB type streams to make them reconnectable. A reconnectable stream can remain “dangling" connected to its end with the keep-type connection while disconnected at its other end. • The default type for all streams is non-reconnectableBK.

5. Streams (3) • A break-type connection between a stream and a port breaks when one of the following happens: • the stream dies • the process to which the port belongs dies • the port is closed or disconnected • the stream is preempted • the stream realizes that the connection at its other end is broken • Preemption of a stream means breaking its break-type connections and it is performed when the manifold changes to another state. • A keep-type connection between a stream and a port breaks either when the stream dies, or when the process to which the port belongs dies. • A stream dies when: • It is disconnected from both its source and its sink OR • It is empty and is disconnected from its source.

6. Events • An event is an asynchronous, non-decomposable (atomic) message, broadcast by a process in its environment, or posted internally within the process. The environment of a process includes all running processes in the same application. • Broadcast of the event by a process to its environment is done by the raise(event_name) command, while internal posting of event is done by the post(event_name) command. Order of events • If a process A raises an event e1 before it raises another event e2, any other process B that observes both occurrences of events e1 and e2 from A is able to observe the occurrence of e1 before it observes the occurrence of e2. • However this does not require that B react on e1 before reacting on e2

7. Events (2) Priorities of events • From the viewpoint of an observer process, events have different priorities associated with them. Event priorities define an ordering on how a given observer process reacts to several observed events. • Event priority declarations are of the form: EventSet1 Relation EventSet2 • Relation can be one of : <, > , = • The priority declaration a>b states that occurrences of a are to be handled before occurrences of b • The priority declaration (a,b,c)=d is identical to the declaration a=d, b=d, c=d. • The priority declarations a<b, b<c implies the declaration a<c

8. Basic Primitive Operations • The activate primitive • Syntax: activate (p1, p2, …, pn) • Explanation: Activates the process instances p1 through pn. • The deactivate primitive • Syntax: deactivate (p1, p2, …, pn) • Explanation: Terminates the process instances p1 through pn. • The raise primitive • Syntax: raise (e1, e2, …, en) • Explanation: Broadcasts the events e1, through en to allprocesses in the running manifold application. The event is received by all process instances in the application except for the process raising the event.

9. Basic Primitive Operations (2) • The post primitive • Syntax: post (e1, e2, …, en) • Explanation: Posts the events e1, through en to the executing manifold instance. No process instance other than the one executing the action is affected. • The shutdown primitive • Syntax: shutdown • Explanation: It broadcasts the predefined terminate event to all processes in the running manifold application, including the one that performs the shutdown action. • The close primitive • Syntax: close (p1, p2, …, pn) • Explanation: Disconnects all streams from the local ports p1 through pn and changes their status in such a way that any attempt to connect a stream to any one of them will fail

10. Basic Primitive Operations (3) • The disconnect primitive • Syntax: disconnect (p1, p2, …, pn) • Explanation: Disconnects all streams from the local ports p1 through pn The status of the ports remains unchanged so • that attempts to connect new streams will succeed. • The open primitive • Syntax: open • Explanation: Opens each of the local ports p1 through pn, which may have been closed. The status of each port pi is changed such that attempts to connect new streams will succeed.

11. Basic Primitive Operations (4) • The preemptall primitive • Syntax: preemptall • Explanation: It states that all process instances that are observable event sources can preempt the state it appears in. Normally, only process instances that are mentioned in the body of a state can be the sources of events that preempt the state. • The guard primitive • Syntax: guard (PortName, Condition, Event) • Explanation: It creates a virtual process that watches the specified port. When the Condition becomes true, it posts the Event in the executing process. (i.e. to the process that has installed the guard, NOT to the process that owns the specified port)

12. Port Conditions • A port condition represents a predicate that is true or false as applied to a port. Port conditions are either simple or composite. Composite port conditions are built out of simple port conditions. Simple port conditions are summarized in the following table and can be of two types: transitory conditions and non-transitory conditions.

13. Port Conditions (2)

14. Port Conditions (3)

15. Port Conditions (4)

16. Port Conditions (5) A transitory condition is one that can be detected only if it is expected, i.e., if there is already a guard installed that is waiting for the transitory condition to become true. The values of transitory conditions are not “remembered" by ports. A non-transitory condition is one whose value is “remembered” by the port. This means that if a non-transitory condition is already true at the time that a guard is installed, the guard will recognize the condition to be true.

17. Port Conditions (6) Composite Port Conditions • Simple port conditions can be combined to build composite port conditions using the ! binary operator. • A composite port condition of the form c1!c2!: : :!cn means wait, if necessary, until c1 is true, then wait, if necessary, until c2 is true, etc., and then wait, if necessary, until cn is true; it is only then that the whole composite port condition is true. • Some examples of useful composite port conditions are: • a_connected!a_disconnected :The last stream is disconnected from the arrival side. • a_disconnected!a_connected :The last stream is connected to the arrival side. • a_disconnected!a_connect : The first stream is connected to the arrival side.

18. Water Installation Example

19. Water Installation Example manifold alarm(port in, event) import. manifold kettle port out radiator. port out tap. forward. auto process k is kettle. /***********************************************************/ manifold kettle port out radiator. port out tap. { event to_rad, to_tap, stop. priority to_tap > to_rad.

20. Water Installation Example (2) stop | begin: ( guard(radiator, d_connected, to_rad), guard(tap, d_connected, to_tap) ); ( "kettle: doesnot send water\n" -> stdout, terminated(void) ). to_tap:{ ignore to_rad. begin: ( guard(radiator, d_connected, noevent), guard(tap, d_disconnected, stop), "kettle: sending water to tap\n" -> stdout, terminated(void) ). }.

21. Water Installation Example (3) to_rad: { begin: ( guard(radiator, d_disconnected, stop), “kettle: sending water to radiator\n" -> stdout, terminated(void) ). to_tap: ( guard(radiator, d_disconnected, noevent), post(stop) ). }. } /***********************************************************/ manifold radiator { event tc, we. we | begin: (alarm(5000, tc),“radiator: off\n" -> stdout, terminated(void) ). tc:( alarm(1000, we), k.radiator -> self.input, "radiator: on\n" -> stdout ). }

22. Water Installation Example (4) manifold tap { event on, off. off | begin: (alarm(2000, on),"tap: off\n" -> stdout, terminated(void) ). on: (alarm(100, off),k.tap -> self.input,"tap: on\n" -> stdout ). } /*********************************************************/ manifold Main { process r is radiator. process t is tap. event geb. begin: ( activate(r, t), alarm(40000, geb), terminated(void) ). geb: deactivate(r, t). }