ManifoldLab 3

Primitive operations, Streams, Events,

A complete example

Summary

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

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.

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-reconnectable BK.

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.

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

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

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 all processes

in the running manifold application. The event is received by all process instances in the application except for the process raising the event.

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

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.

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)

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.

Condition name Type Meaning

a_connect transitory A connection is made to the arrival side.

a_connected non-transitory There is at least one connection on the arrival side.

a_disconnect transitory A disconnection is made on the arrival side.

Port Conditions (2)

Condition name Type Meaning

a_disconnected non-transitory There is no connection on the arrival side.

a_everconnected non-transitory At least once since the creation of the process instance, the condition a_connected has been true.

a_everdisconnected non-transitory The condition a_disconnected was/is true at least once after the condition a_everconnected became true.

Port Conditions (3)

Condition name Type Meaning

d_connect transitory A connection is made to the departure side.

d_connected non-transitory There is at least one connection on the departure side.

d_disconnect transitory A disconnection is made on the departure side.

d_disconnected non-transitory There is no connection on the departure side.

Port Conditions (4)

Condition name Type Meaning

d_everconnected non-transitory At least once since the creation of the process instance, the condition d_connected has been true.

d_everdisconnected non-transitory The condition a_disconnected was/is true at least once after the condition d_everconnected became true.

full non-transitory At least one unit is available on the arrival side of the port.

Port Conditions (5)

Condition name Type Meaning

empty non-transitory There is at least one stream containing no units connected to the departure side.

transport non-transitory A unit passed through the port

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.

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.

Water Installation Example

k e ttle

radia to r

tap

ra d ia to r

ta p

Water Installation Example

manifold alarm(port in, event) import.manifold kettle

port out radiator.port out tap.

forward.auto process k is kettle.

/***********************************************************/

manifold kettleport out radiator.port out tap.

{ event to_rad, to_tap, stop. priority to_tap > to_rad.

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) ).

}.

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 ).}

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). }