VDM-10 Language Manual

Chapter 15. Synchronization Constraints (VDM++ and VDM-RT)
Constraints for safe execution of the operations Push and Pop in a stack object can be
expressed using an object state guard as:
✞
per Push => length < maxsize;
per Pop => length > 0
✡✝
where maxsize and length are instance variables of the stack object.
It is often possible to express such constraints as a consequence of the history, for example
the empty state of the stack:
✞
✡✝
length = 0 #fin(Push) = #fin(Pop)
However, the size is a property which is better regarded as a property of the particular stack
instance, and in such cases it is more elegant to use available instance variables which store
the effects of history.
✆
✆
15.1.3 Queue condition guards
Semantics: A queue condition guard acts on requests waiting in the queues for the execution of
the operations. This requires use of a third history function #req such that #req(A) counts
the number of messages which have been received by the object requesting execution of operation
A. Again it is useful to introduce the function #waiting such that: #waiting(A)
= #req(A) - #act(A), which counts the number of items in the queue.
Examples: Once again, with the web server we can only activate the ServerBusy operation if
100 or more connections are waiting:
✞
per ServerBusy => #waiting(RetrieveURL) +
#waiting(ExecuteCGI) >= 100;
✡✝
The most important use of such expressions containing queue state functions is for expressing
priority between operations. The protocol specified by:
✞
per B => #waiting(A) = 0
✡✝
gives priority to waiting requests for activation of A. There are, however, many other situations
when operation dispatch depends on the state of waiting requests. Full description
of the queuing requirements to allow specification of operation selection based on request
arrival times or to describe ‘shortest job next’ behaviour will be a future development.
141
✆
✆