VDM-10 Language Manual

VDM-10 Language Manual
Note that #req(A) have value 1 at the time of evaluation of the permission predicate for
the first invocation of operation A. That is,
✞
per A => #req(A) = 0
✡✝
would always block.
✆
15.1.4 Evaluation of Guards
Using the previous example, consider the following situation: the web server is handling 10
RetrieveURL requests already. While it is dealing with these requests, two further RetrieveURL
requests (from objects O 1 and O 2 ) and one ExecuteCGI request (from object O 3 ) are received.
The permission predicates for these two operations are false since the number of active RetrieveURL
operations is already 10. Thus these objects block.
Then, one of the active RetrieveURL operations reaches completion. The permission predicate
so far blocking O 1 , O 2 and O 3 will become “true” simultaneously. This raises the question:
which object is allowed to proceed? Or even all of them?
Guard expressions are only reevaluated when an event occurs (in this case the completion of a
RetrieveURL operation). In addition to that the test of a permission predicate by an object and
its (potential) activation is an atomic operation. This means, that when the first object evaluates its
guard expression, it will find it to be true and activate the corresponding operation (RetrieveURL
or ExecuteCGI in this case). The other objects evaluating their guard expressions afterwards will
find that #active(RetrieveURL) + #active(ExecuteCGI) = 10 and thus remain
blocked. Which object is allowed to evaluate the guard expression first is undefined.
It is important to understand that the guard expression need only evaluate to true at the time of
the activation. In the example as soon as O 1 , O 2 or O 3 ’s request is activated its guard expression
becomes false again.
15.2 Inheritance of Synchronization Constraints
Synchronization constraints specified in a superclass are inherited by its subclass(es). The manner
in which this occurs depends on the kind of synchronization.
15.2.1 Mutex constraints
Mutex constraints from base classes and derived classes are simply added. If the base class and
derived class have the mutex definitions M A and M B , respectively, then the derived class simply
has both mutex constraints M A , and M B . The binding of operation names to actual operations is
always performed in the class where the constraint is defined. Therefore a mutex(all) constraint
defined in a superclass and inherited by a subclass only makes the operations from the base
class mutually exclusive and does not affect operations of the derived class.
142