Resources can be encapsulated and accessed only through a high-level interface (a package in Ada).
In Ada – If the resource manager is a server then the package body will contain a task (or an access object to a task type). A protected resource will use a protected object within the package body.
In Java – protected resources are naturally encapsulated within a monitor.
The ‘information’ needed to express synchronisation constraints can be categorised:
- The type of service request.
- The order of the requests.
- The state of the server and any other objects.
- The parameters of the request.
- The history of the object (e.g. all previous service requests in order).
- The priority of the client/request.
Most synchronisation methods can cope with all of these, though parameters cause problems, apparently.
Conditional Waits and Avoidance
There are (generally) two approaches to constraining access to a service.
- Conditional Wait: All requests are accepted, but if a task’s request cannot be met then it is suspended on some sort of queue.
- Avoidance: Requests are not accepted unless they can be met.
Requeue in Ada
The Requeue facility in Ada enhances the usability of avoidance synchronisation. It moves the task (which has been through one guard or barrier) to beyond another guard.
- Requeues between task and protected object entries/
- A requeue to be to the same entry, to another entry in the same unit, or to another unit altogether.
The main use is to send the calling task to a different entry of the same unit.
Requeue is not just an entry call; if an entry call is ‘requeue’ then the call is completed – anything after the
requeue Entry_Name will not be executed.
You can requeue tasks across different objects so long as they are type conferment.
This might require looking up in some Ada manual or giving it a try; the lecture slides make it sound more complex than it is and I missed the lecture.