Resuming Process Monitoring for a Process Instance

If several processes are suspended on condition x, and an x.signal() operation is executed by some process, then we can determine that which of the suspended processes should be resumed next by one simple solution is to use a first-come, first-served (FCFS) ordering, so that the process that has been waiting the longest is resumed first. In many circumstances, however, such a simple scheduling scheme is not adequate. For this reason, the conditional-wait construct can be used. This construct has the form

x.wait(c);

Here c is an integer expression that is evaluated when the wait() operation is executed. The value of c, is called a priority number, is then stored with the name of the process that is suspended. When x.signal() is executed, the process with the smallest priority number is resumed next. To illustrate this new mechanism, consider the ResourceAllocator monitor shown in below code, which controls the allocation of a single resource among competing processes.

Example

monitor ResourceAllocator{
   boolean busy;
   condition x;
   void acquire(int time){
   if (busy)
      x.wait(time);
      busy = true;
   }
   void release(){
      busy = false;
      x.signal();
   }
   initialization code(){
      busy = false;
   }
}

When an allocation of this resource is requested by each process, specifies the maximum time it plans to use the resource. The resource is allocated by The monitor to the process that has the shortest time-allocation request. A process that needs to access the resource in above question must observe the following sequence −

R.acquire(t);
...
access the resource;
…
R.release();

where R is an instance of type ResourceAllocator.

The monitor concept cannot guarantee that the preceding access sequence will be observed, unfortunately, the following problems can be occurred −

• Without first gaining access permission to the resource, a process might access a resource.

• Once a process has been granted access to the resource, it might never release a resource.

• A process might try to release a resource that it never requested.

• Same resource might be requested twice (without first releasing the resource) by a process.

One possible solution to the current problem is to include the resource access operations within the ResourceAllocator monitor. However, using this solution will mean that scheduling is done according to the built-in monitor-scheduling algorithm rather than the one we have coded.

We must inspect all the programs that make use of the ResourceAllocator monitor and its managed resource, to ensure that the processes observe the appropriate sequences. Two conditions it is must to establish the correctness of this system. At First, user processes must always make their calls on the monitor in a correct sequence, and second, it is must to ensure that an uncooperative process does not simply ignore the mutual-exclusion gateway provided by the monitor and try to access the shared resource directly, without using the access protocols. Only if these two conditions can be ensured can we guarantee that no time-dependent errors will occur and that the scheduling algorithm will not be defeated.