You are on page 1of 15

Monitors

Dr. Nikhil Kothari


Department of Electronics & Communication Eng.
Faculty of Technology
Dharmsinh Desai University
Monitors

• Difficulties with scattered semWait/Signal call.

• Not easy to see over all effect on semaphores.

• Monitors
equivalent functionality of semaphores
easier to control.
Monitor Characteristics

1. Local data accessible to monitor procedures only.

2. Monitor entry by invoking one of procedures.

3. only one process executing in monitor at a time


• other processes blocked.

shared data protected in monitor

mutual exclusion
Monitor as an object.
Monitor Module

• Procedures

• Initialization sequence

• Local data
Synchronization

•Until condition satisfied, process blocked.

•Release monitor for other process to enter.

•Condition satisfied – resume process in available monitor.

•Condition variables in monitor.

•Accessible with monitor.


Condition Variables

Contained and accessible Within the monitor

Operated by functions

cwait(c) – suspend calling process


monitor available for another process

csignal(c) – resume process blocked after cwait(c)


Monitor Module
Monitor Module
Monitor Module
Monitor vs Semaphore

Automatic Mutual Exclusion

Buffer full - producer will be able to complete the WAIT

consumer will not even be let into the monitor until the WAIT is finished

producer has been marked as no longer runnable.

Synchronization confined to monitor – easy to verify and detect bugs

Access to protected resource correct for all processes


All processes to be programmed correctly in semaphore

Parallel programming less error prone

User programs for semaphore in c / c++

Monitors need built in support in languages


Message Passing
Design Issues

• Communicating process on different machines.

•Message come or lost.

•Acknowledgement.

•Retransmission – duplication.

•Process naming

•Authentication.

•Copying message slower than semaphore / monitor

•message passing using the register.


Procedure Consumer with Message Passing

void producer(void) {
int item;
message m; /* message buffer */
while (TRUE) {
produce-item(&item); /* generate something to put in buffer */
receive(consumer&, m); I* wait for an empty to arrive *I
build-message(&m, item); /* construct a message to send */
send(consumer, &m); /* send item to consumer *I
}
}
void consumer(void) {
int item, i;
•Faster procedure message m;
blocked. for (i = 0; i < N; i++) send(producer, &m); /* send N empties */
•Waiting for empty while (TRUE) {
to come. receive(producer, &m); /* get message containing item *I
•Faster consumer extract-item(&m, &item); I* extract item from message *I
send(producer, &m); I* send back empty reply *I
waiting consume-item(item); /* do something with the item */
for procedure }
to fill up.
}
Message passing - Variants

•Messages addressed to process.

•Mailbox address parameters in SEND/RECEIVE


full / empty.

•Destination mailbox – messages sent to process yet not


accepted.

•Message directly from sender to receiver .

•No intermediate buffering.


Pipe

•No message boundries.

•10 messages 100 bytes = 1000 bytes

•True message system - fixed size messages in pipe . Special


character at end.

You might also like