Monitors

Monitors

• Monitor is an object that contains both data and procedures needed to perform allocation of a shared resource. It is a programming language construct that support both data access synchronization and control synchronization.

• Fig. 2.15.1 shows structure of monitor. (See Fig. 2.15.1 on next page.)

• Monitor is implemented in programming languages like Pascal, java and C++. Java makes extensive use of monitors to implement mutual exclusion.

• Monitor is an abstract data type for which only one process may be executing a procedure at any given time. Monitor is a collection of procedure, variables and data structure. Data inside the monitor may be either global to all routines within the monitor or local to a specific routine.

• Monitor data is accessible only within the monitor. A shared data structure can be protected by placing it in a monitor. If the data in a monitor represents some resource, then the monitor provides a mutual exclusion facility for accessing the resource. A procedure defined within a monitor can access only those variable declared locally within the monitor and its formal parameters.

• When a process calls a monitor procedure, the first few instruction of the procedure will check to see if any other process is currently active within the monitor. If process is active then calling process will be suspended until the other process has left the monitor. If no other process is using the monitor, the calling process may enter.

• Monitor supports synchronization by the use of condition variables that are contained within the monitor and accessible only within the monitor. Every conditional variable has an associated queue. Condition variables operates on two

cwait(condition variable)

csignal (condition variable)

• cwait: It suspend execution of the calling process on condition.

• csignal: Resume execution of some process blocked after a cwait on the same condition.

• The cwait must come before the csignal.

• Fig. 2.15.2 shows monitor structure with condition variables.

• CPU is a resource that must be shared by all processes. The part of the kernel that apportions CPU time between processes is called the scheduler.

• A condition variable is like a semaphore, with two differences:

1. A semaphore counts the number of excess up operations, but a signal operation on a condition variable has no effect unless some process is waiting. A wait on a condition varibale always blocks the calling process.

2. A wait on a condition variable automatically does an up on the monitor mutex and blocks the caller.

Example: Solve producer consumer problem by using monitors

Bounded Buffer problem using monitors

monitor Bounded Buffer

{

private Buffer b = new Buffer (20); 

private int count = 0;

private condition nonfull, nonempty;

public void add (object item)

}

if(count == 20)

nonfull.wait();

b.add (item);}

count ++;

nonempty. signal ();

}

public object remove ()

{

if (count == 0) 

nonempty.wait();

item result = b.remove();

count count-1;

nonfull.signal();

return result;

• Each condition variable is associated with some logical condition on the state of the monitor. Consider what happens when a consumer is blocked on the nonempty condition variable and producer calls add.

1. The producer adds the item to the buffer and calls nonempty signal ( ).

2. The producer is immediately blocked and the consumer is allowed to continue. 3. The consumer removes the item from the buffer and leaves the monitor.

4. The producer wakes up and since the signal operation wait the last statement in add, leaves the monitor.

• Monitors are a higher level concept than P and V. They are easier and safer to use but less flexible. Many languages are not supported by the monitor. Java is making monitors much more popular and well known.

Example 2.15.1 Solve the reader-writer problem using monitor with readers priority.

Solution :

readers-writers: monitor;

begin

integer readercount;

condition okread, okwrite;

boolean busy;

procedure startread;

begin

if busy then ok read.wait;

readercount := readercount+1;

okread.signal;

end startread;

procedure endread;

begin

reader count:= readercount-1;

if      reader count = 0 then okwrite.signal;

end endread;

procedure startwrite;

begin if busy OR readercount ≠ 0 then okwrite.wait;

busy = true;

end startwrite;

procedure endwrite;

begin

busy := false;

if okread.queue then okread.signal

else okwrite.signal

end endwrite;

begin (*Initialisation*)

readercount :=0;

busy: =false;

end;

end readers-writers;

Example 2.15.2 Solve procedure-consumer problem with monitors.

Solution :

monitor procedure-consumer

condition full empty;

integer count;

Procedure insert (item: integer);

begin

if count = N then wait (full);

insert-item(item);

count: = count+1;

if count = 1 then signal (empty)

end;

function remove:integer;

begin

if count = 0 then wait (empty);

remove = remove_item;

count = count-1;

if count = N-1 then signal (full);

end;

count := 0;

end monitor;

procedure producer;

begin

while true do

begin

item = produce_item;

producer_consumer.insert(item)

end

end;

procedure consumer;

begin

while true do

begin

item procedure_consumer.remove;

consume_item(item)

end

end;

• By making the mutual exclusion of critical regions automatic, monitors make parallel programming much less error prone than with semaphores.

2.15.1 Drawbacks of Monitors

1. Major weakness of monitors is the absence of concurrency if a monitor encapsulates the resource, since only one process can be active within a monitor at a time.

2. There is the possibility of deadlocks in the case of nested monitors calls.

3. Monitor concept is its lack of implementation most commonly used programming languages.

4. Monitors cannot easily be added if they are not natively supported by the language.

2.15.2 Difference between Monitors and Semaphore

• A semaphore is an operating system abstract data type whereas monitors are based on abstract data types.

• Semaphore-level synchronization primitives are difficult to use for complex synchronization situations. Monitors were derived to simplify the complexity of synchronization problems by abstructing away details.

• Semaphores provide a general-purpose mechanism for controlling access to critical sections. Their use does not guarantee that access will be mutually exclusive or deadlock will be avoided. A monitor is a programming language construct that guarantees appropriate access to critical sections.

Monitor uses condition variables. A condition variable is like a semaphore, with two differences

1) A semaphore counts the number of excess up operations, but a signal operation on a condition variable has no effect unless some process is waiting. A wait on a condition variable always blocks the calling process.

2) A wait on a condition variable automatically does an up on the monitor mutex and blocks the caller.

Example 2.15.3 Dining-philosopher critical section problem solution using monitor. AU: May-19, Marks 13

Solution: Below solution imposes the restriction that a philosopher may pick up her chopsticks only if both of them are available. Here we consider, three state with datastructure.

enum {THINKING, HUNGRY, EATING} state[5];

• Philosopher i can set the variable state[i] = EATING only if her two neighbors are not eating: (state[(1+4) % 5] != EATING) and(state[(i+1) % 5] != EATING).

monitor DiningPhilosophers

enum {THINKING, HUNGRY, EATING} state[5];

condition self[5];

void pickup(int i)

{

state[i] = HUNGRY;

test(i);

if (state[i]!= EATING)

self[i].wait();

}

void putdown(int i)

state[i] THINKING;

test((i + 4) % 5);

test((i + 1) % 5);

void test(int i)

if ((state[(i + 4) % 5] != EATING) && (state[i] == HUNGRY) && (state[(i + 1)% 5] != EATING))

{

state[i] EATING;

self[i].signal();

}

}

initialization code()

{

for (int i = 0; i< 5; i++)

state[i]= THINKING;

}

}

University Question

1. Explain the dining-philosopher critical section problem solution using monitor.