Modern Operating Systems by Herbert Bos ...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
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
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.
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
to a process identified by
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
and the called is unblocked. The
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
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
). When a process calls
, 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
is not executed until
the message has been completely sent, as shown in Fig. 8-19(a). Similarly, a call
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
until a message arrives, even if it takes hours.
In some systems,

Page 585
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
Trap to kernel,
sender blocked
Message being sent
Message being sent
Sender running
Sender running
Sender running
Sender running
copied to a
kernel buffer
Return from kernel,
sender released
Figure 8-19.
(a) A blocking send call. (b) A nonblocking send call.
An alternative to blocking calls is the use of
nonblocking calls
asynchronous calls
). If
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).
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.

Ace your assessments! Get Better Grades
Browse thousands of Study Materials & Solutions from your Favorite Schools
Concordia University
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

Students also viewed documents