VDM-10 Language Manual

Chapter 15. Synchronization Constraints (VDM++ and VDM-RT)
• a queue condition guard, which depends on the states of the queues formed by operation
invocations (messages) awaiting service by the object.
These guards can be freely mixed. Note that there is no syntactic distinction between these
guards - they are all expressions. However they may be distinguished at the semantic level.
A mutex predicate allows the user to specify either that all operations of the class are to be
executed mutually exclusive, or that a list of operations are to be executed mutually exclusive
to each other. Operations that appear in one mutex predicate are allowed to appear in other
mutex predicates as well, and may also be used in the usual permission predicates. Each
mutex predicate will implicitly be translated to permission predicates using history guards
for each operation mentioned in the name list. For instance,
✞
sync
mutex(opA, opB);
mutex(opB, opC, opD);
per opD => someVariable > 42;
✡✝
✆
would be translated to the following permission predicates:
✞
sync
per opA => #active(opB) = 0;
per opB => #active(opA) = 0 and
#active(opC) + #active(opD) = 0;
per opC => #active(opB) + #active(opD) = 0;
per opD => #active(opB) + #active(opC) = 0 and
someVariable > 42;
✡✝
✆
Note that it is only permitted to have one permission predicate for each operation. The
#active operator is explained below.
A mutex(all) constraint specifies that all of the operations specified in that class and any
superclasses are to be executed mutually exclusively.
15.1.1 History guards
Semantics: A history guard is a guard which depends on the sequence of earlier invocations of the
operations of the object expressed in terms of history expressions (see section 6.22). History
expressions denotes the number of activations and completions of the operations, given as
functions
#act and #fin, respectively.
139