MESSAGE
| DATE | 2015-04-13 |
| FROM | Ruben Safir
|
| SUBJECT | Subject: [LIU Comp Sci] Chapter 5 Monitor
|
From owner-learn-outgoing-at-mrbrklyn.com Mon Apr 13 12:02:54 2015
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id A013916116C; Mon, 13 Apr 2015 12:02:54 -0400 (EDT)
Delivered-To: learn-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id 8DE58161170; Mon, 13 Apr 2015 12:02:54 -0400 (EDT)
Delivered-To: learn-at-nylxs.com
Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89])
by mrbrklyn.com (Postfix) with ESMTP id 766D416116C
for ; Mon, 13 Apr 2015 12:02:29 -0400 (EDT)
Received: from [10.0.0.19] (www.mrbrklyn.com [96.57.23.82])
by mailbackend.panix.com (Postfix) with ESMTPSA id A4ECB12E19
for ; Mon, 13 Apr 2015 12:02:29 -0400 (EDT)
Message-ID: <552BE895.1020009-at-panix.com>
Date: Mon, 13 Apr 2015 12:02:29 -0400
From: Ruben Safir
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: learn-at-nylxs.com
Subject: [LIU Comp Sci] Chapter 5 Monitor
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Sender: owner-learn-at-mrbrklyn.com
Precedence: bulk
Reply-To: learn-at-mrbrklyn.com
Does anyone at all understand this monitor section in Chapter 5 of the
textbook?
Figure 5.15 Syntax of a monitor.
5.8.1
Monitor Usage
An abstract data type—or ADT —encapsulates data with a set of functions
to operate on that data that are independent of any specific implementation
of the ADT. A monitor type is an ADT that includes a set of programmer-
defined operations that are provided with mutual exclusion within the
monitor.
The monitor type also declares the variables whose values define the state
of an instance of that type, along with the bodies of functions that operate
on those variables. The syntax of a monitor type is shown in Figure 5.15.
The representation of a monitor type cannot be used directly by the various
processes. Thus, a function defined within a monitor can access only those
variables declared locally within the monitor and its formal parameters.
Similarly, the local variables of a monitor can be accessed by only the
local
functions.
The monitor construct ensures that only one process at a time is active
within the monitor. Consequently, the programmer does not need to code
this synchronization constraint explicitly (Figure 5.16). However, the
monitor
construct, as defined so far, is not sufficiently powerful for modeling some
synchronization schemes. For this purpose, we need to define additional syn-
chronization mechanisms. These mechanisms are provided by the condition
construct. A programmer who needs to write a tailor-made synchronization
scheme can define one or more variables of type condition:
condition x, y;
226
Chapter 5ProcessSynchronization
shared data
entry queue
. . .
operations
initialization
code
Figure 5.16 Schematic view of a monitor.
The only operations that can be invoked on a condition variable are wait()
and signal(). The operation
x.wait();
means that the process invoking this operation is suspended until another
process invokes
x.signal();
The x.signal() operation resumes exactly one suspended process. If no
process is suspended, then the signal() operation has no effect; that
is, the
state of x is the same as if the operation had never been executed (Figure
5.17). Contrast this operation with the signal() operation associated with
semaphores, which always affects the state of the semaphore.
Now suppose that, when the x.signal() operation is invoked by a process
P, there exists a suspended process Q associated with condition x.
Clearly, if the
suspended process Q is allowed to resume its execution, the signaling
process
P must wait. Otherwise, both P and Q would be active simultaneously within
the monitor. Note, however, that conceptually both processes can continue
with their execution. Two possibilities exist:
1.2.Signal and wait. P either waits until Q leaves the monitor or waits for
another condition.
Signal and continue. Q either waits until P leaves the monitor or waits
for another condition.
queues associated with
x, y conditions
x
y
shared data
entry5.8 Monitors
queue
227
• • •
operations
initialization
code
Figure 5.17 Monitor with condition variables.
There are reasonable arguments in favor of adopting either option. On
the one hand, since P was already executing in the monitor, the signal-and-
continue method seems more reasonable. On the other, if we allow thread P
to continue, then by the time Q is resumed, the logical condition for
which Q
was waiting may no longer hold. A compromise between these two choices
was adopted in the language Concurrent Pascal. When thread P executes the
signal operation, it immediately leaves the monitor. Hence, Q is immediately
resumed.
Many programming languages have incorporated the idea of the monitor
as described in this section, including Java and C# (pronounced “C-sharp”).
Other languages—such as Erlang—provide some type of concurrency support
using a similar mechanism.
|
|
