|
|
|
Modern Operating Systems by Herbert Bos and Andrew S. Tanenb...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf
Showing 584-585 out of 1137
Modern Operating Systems by Herbert Bos and Andrew...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Modern Operating Systems by Herbert...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Page 584
SEC. 8.2
MULTICOMPUTERS
553
8.2.3 User-Level Communication Software
Processes on different CPUs on a multicomputer communicate by sending
messages to one another.
In the simplest form, this message passing is exposed to
the user processes.
In other words, the operating system provides a way to send
and receive messages, and library procedures make these underlying calls available
to user processes.
In a more sophisticated form, the actual message passing is hid-
den from users by making remote communication look like a procedure call.
We
will study both of these methods below.
Send and Receive
At the barest minimum, the communication services provided can be reduced
to two (library) calls, one for sending messages and one for receiving them. The
call for sending a message might be
send(dest, &mptr);
and the call for receiving a message might be
receive(addr, &mptr);
The former sends the message pointed to by
mptr
to a process identified by
dest
and causes the called to be blocked until the message has been sent. The latter
causes the called to be blocked until a message arrives. When one does, the mes-
sage is copied to the buffer pointed to by
mptr
and the called is unblocked. The
addr
parameter specifies the address to which the receiver is listening. Many vari-
ants of these two procedures and their parameters are possible.
One issue is how addressing is done. Since multicomputers are static, with the
number of CPUs fixed, the easiest way to handle addressing is to make
addr
a two-
part address consisting of a CPU number and a process or port number on the ad-
dressed CPU.
In this way each CPU can manage its own addresses without poten-
tial conflicts.
Blocking versus Nonblocking Calls
The calls described above are
blocking calls
(sometimes called
synchronous
calls
). When a process calls
send
, it specifies a destination and a buffer to send to
that destination. While the message is being sent, the sending process is blocked
(i.e., suspended).
The instruction following the call to
send
is not executed until
the message has been completely sent, as shown in Fig. 8-19(a). Similarly, a call
to
receive
does not return control until a message has actually been received and
put in the message buffer pointed to by the parameter. The process remains sus-
pended in
receive
until a message arrives, even if it takes hours.
In some systems,
Page 585
554
MULTIPLE PROCESSOR SYSTEMS
CHAP. 8
the receiver can specify from whom it wishes to receive, in which case it remains
blocked until a message from that sender arrives.
Sender blocked
Sender
blocked
Trap to kernel,
sender blocked
Message being sent
Message being sent
Sender running
Sender running
Return
Sender running
Sender running
Trap
Message
copied to a
kernel buffer
Return from kernel,
sender released
(a)
(b)
Figure 8-19.
(a) A blocking send call. (b) A nonblocking send call.
An alternative to blocking calls is the use of
nonblocking calls
(sometimes
called
asynchronous calls
). If
send
is nonblocking, it returns control to the called
immediately, before the message is sent. The advantage of this scheme is that the
sending process can continue computing in parallel with the message transmission,
instead of having the CPU go idle (assuming no other process is runnable).
The
choice between blocking and nonblocking primitives is normally made by the sys-
tem designers (i.e., either one primitive is available or the other), although in a few
systems both are available and users can choose their favorite.
However, the performance advantage offered by nonblocking primitives is off-
set by a serious disadvantage: the sender cannot modify the message buffer until
the message has been sent. The consequences of the process overwriting the mes-
sage during transmission are too horrible to contemplate. Worse yet, the sending
process has no idea of when the transmission is done, so it never knows when it is
safe to reuse the buffer.
It can hardly avoid touching it forever.
There are three possible ways out. The first solution is to have the kernel copy
the message to an internal kernel buffer and then allow the process to continue, as
shown in Fig.8-19(b). From the sender’s point of view, this scheme is the same as
a blocking call: as soon as it gets control back, it is free to reuse the buffer.
Of
Ace your assessments! Get Better Grades
Browse thousands of Study Materials & Solutions from your Favorite Schools
Concordia University
Concordia_University
School:
Operating_Systems
Course:
Great resource for chem class. Had all the past labs and assignments
Leland P.
Santa Clara University
Introducing Study Plan
Using AI Tools to Help you understand and remember your course concepts better and faster than any other resource.
Find the best videos to learn every concept in that course from Youtube and Tiktok without searching.
Save All Relavent Videos & Materials and access anytime and anywhere
Prepare Smart and Guarantee better grades
Know more
Students also viewed documents
lab 18.docx
lab_18.docx
Course
Course
3
Module5QuizSTA2023.d...
Module5QuizSTA2023.docx.docx
Course
Course
10
Week 7 Test Math302....
Week_7_Test_Math302.docx.docx
Course
Course
30
Chapter 1 Assigment ...
Chapter_1_Assigment_Questions.docx.docx
Course
Course
5
Week 4 tests.docx.do...
Week_4_tests.docx.docx
Course
Course
23
Week 6 tests.docx.do...
Week_6_tests.docx.docx
Course
Course
106
