Language Reference/Monitors

A monitor is a language construction to synchronize two or more threads that use a shared resource, usually a hardware device or a set of variables. The compiler transparently inserts locking and unlocking code to appropriately designated procedures, instead of the programmer having to access concurrency primitives explicitly.

Visual Prolog monitor entrances can be controlled by guard predicates (conditions).

Syntax
Monitor interfaces and monitor classes are scopes: A monitor interface is defined by writing the keyword monitor in front of a regular interface definition:

A monitor class is declared by writing the keyword monitor in front of a regular class declaration: Monitor classes and interfaces cannot declare multi and nondeterm predicate members.

Restrictions

 * A regular interface cannot support a monitor interface
 * A monitor class cannot construct objects.
 * It is not legal to inherit from a monitor (i.e. from a class that implements a monitor interface).

Semantics
The predicates and properties declared in a monitor are the entrances to the monitor. A thread enters the monitor through an entrance and is in the monitor until it leaves that entrance again. Only one thread is allowed to be in the monitor at the time. So each entry is protected as a critical region.

The semantics is simplest to understand as a program transformation (which is how it is implemented). Consider this academic example: monitor class mmmm predicates e1 : (a1 A1). e2 : (a2 A2). ...   en : (an An). end class mmmm

%- implement mmmm clauses e1(A1) :- .

clauses e2(A2) :- .

... clauses en(An) :- . end implement mmmm Where , , ...,  are clause bodies. This code corresponds to the following "normal" code: class mmmm predicates e1 : (a1 A1). e2 : (a2 A2). ...   en : (an An). end class mmmm

%- implement mmmm class facts monitorRegion : mutex := mutex::create(false).

clauses e1(A1) :- _W = monitorRegion:wait, try  finally monitorRegion:release end try.

clauses e2(A2) :- _W = monitorRegion:wait, try  finally monitorRegion:release end try. ... clauses en(An) :- _W = monitorRegion:wait, try  finally monitorRegion:release end try. end implement mmmm So each monitor class is extended with a mutex, which is used to create a critical region around each entry body.

The code for monitor objects is similar, except that the mutex object is owned by the object.

Guards
Consider a monitor protected queue: some threads (producers) inserts elements in the queue and others (consumers) pick-out elements. However, you cannot pick-out elements if the queue is empty.

If we implement the queue using a monitor, the "pick-out" entry could be determ, failing if the queue is empty. But then the consumers would have to "poll" the queue until an element can be obtained. Such polling uses system resources, and normally it is desirable to avoid polling. This problem can be solved by guard predicates.

Each entry can have a guard associated in the implementation. The guard is added as a special guard-clause before the other clauses of the entry.

 : one of   ...    .

 : one of    guard .  guard .

The guard predicates are evaluated when the monitor is created. For monitor classes this means at program start, for object predicates this is immediately after the construction of the object. The guard predicates are also evaluated whenever a tread leaves the monitor. But they are not evaluated at any other time.

If a certain guard succeeds the corresponding entry is open, if it fails the entry is closed.

It is only possible to enter open entries.

Guard predicates are handled in the transformation mentioned above.

An event is created for each guard predicate; this event is set to signaled if the guard predicate succeeds. As mentioned it is set during the creation of the monitor and each time a predicate leaves the monitor (before it leaves the critical region).

When entering an entry the threads waits both for the monitorRegion and for the guard event to be in signalled state.

In the code above the initialization of the class itself and the guard events are done in an undetermined order. But actually it is ensured that the guard events are initialized after all other class/object initialization is performed.

Examples of practical usage
This section shows a few cases where monitors are handy.

Writing to a log file
Several threads needs to log information to a single log file.

monitor class log properties logStream : outputStream. predicates write : (...). end class log

%- implement log class facts logStream : outputStream := erroneous. clauses write(...) :- logStream:write(time::new:formatShortDate, ": "), logStream:write(...), logStream:nl. end implement log

The monitor ensures that writing of a log lines are not mixed with each other, and that stream changes only takes place between writing of log lines.

Shared output streams
This monitor can be used to thread protect the operations of an output stream: monitor interface outputStream_sync supports outputStream end interface outputStream_sync

%- class outputStream_sync : outputStream_sync constructors new : (outputStream Stream). end class outputStream_sync

%- implement outputStream_sync delegate interface outputStream to stream

facts stream : outputStream.

clauses new(Stream) :- stream := Stream. end implement outputStream_sync

You should realize however that with code like this:

clauses write(...) :- logStream:write(time::new:formatShortDate, ": "), logStream:write(...), logStream:nl.

consists of three separate operations, so it can still be the case (fx) that two threads first write the time and then one writes the "...", etc.

Queue
The queue above is fine, but actually it may be better to create queue objects. Using generic interfaces we can create a very general queue:

monitor interface queue{@Elem} predicates enqueue : (@Elem Value). predicates dequeue : -> @Elem Value. end interface queue

%- class queue{@Elem} : queue{@Elem} end class queue

%- implement queue{@Elem} facts value_fact : (@Elem Value).

clauses enqueue(V) :- assert(value_fact(V)).

clauses dequeue guard { value_fact(_), ! }.   dequeue = V :- retract(value_fact(V)), !.   dequeue = V :- common_exception::raise_error(....). end implement queue

Notice that PFC contains a similar class <vp>monitorQueue</vp> already.