Semaphores can be very useful for
solving concurrency problems, but only if programmers use them
properly. If even one process fails to abide by the proper use of
semaphores, either accidentally or deliberately, then the whole system breaks
down. For this reason a higher-level language construct has been developed,
called monitors.
Monitor Usage
- A monitor is essentially a class, in which all data is private, and with the special restriction that only one method within any given monitor object may be active at the same time. An additional restriction is that monitor methods may only access the shared data within the monitor and any data passed to them as parameters. i.e. they cannot access any data external to the monitor.
In order to fully realize the
potential of monitors, one additional new data type, known as a condition
can be defined.
- A
variable of type condition has only two legal operations, wait and signal. i.e.
if X was defined as type condition, then legal operations would be X.wait(
) and X.signal( )
- The
wait operation blocks a process until some other process calls signal, and
adds the blocked process onto a list associated with that condition.
- The signal process does nothing if there are no processes waiting on that condition. Otherwise it wakes up exactly one process from the condition's list of waiting processes.
·
But
now there is a potential problem - If process P within the monitor issues a
signal that would wake up process Q also within the monitor, then there would
be two processes running simultaneously within the monitor, violating the
exclusion requirement.
·
Accordingly
there are two possible solutions to this dilemma:
Signal and wait - When
process P issues the signal to wake up process Q, P then waits, either for Q to
leave the monitor or on some other condition.
Signal and
continue -
When P issues the signal, Q waits, either for P to exit the monitor or for some
other condition.
No comments:
Post a Comment