Download Lecture 3 Processes and Communication

ADVANCED
OPERATING SYSTEMS
Lecture 3
Processes and Communication
by:
Syed Imtiaz Ali
1
Categories of Concurrent Processes
• Processes executing concurrently:
– Independent processes
– Cooperating processes.
• Independent Process
– cannot affect other processes
– Can not be affected by the other
processes
– Does not share data with any other
process is independent.
2
Categories of Concurrent Processes
• Cooperating process:
– Can affect other processes
– Can be affected by the other processes
– Shares data with other processes
• Cooperating processes require an
interprocess communication (IPC)
mechanism that will allow them to exchange
data and information.
3
Reasons of Cooperation (1)
1. Information sharing.
– Users may be interested in the same piece of
information (for instance, a shared file)
2. Computation speedup.
– A particular task may break up into subtasks,
each of which will be executing in parallel.
– Such a speedup can be achieved only if the
computer has multiple processing elements
(such as CPUs or I/O channels).
4
Reasons of Cooperation (2)
3. Modularity.
– We may want to construct the system in a
modular fashion, dividing the system functions
into separate processes or threads.
4. Convenience.
– Even an individual user may work on many
tasks at the same time.
– For instance, a user may be editing, printing,
and compiling in parallel.
5
Interprocess Communication Models
• There are two fundamental models of
interprocess communication (IPC):
– shared memory
– message passing
• In the shared-memory model, processes can
exchange information by reading and
writing data to the shared region.
• In the message passing model,
communication takes place by means of
messages exchanged between them
6
(a) Message Passing Model
(b)Shared Memory Model
7
Comparing The Two Models
• Message passing is:
– Useful for exchanging smaller amounts of data,
because no conflicts need be avoided.
– Easier to implement than is shared memory.
• Shared memory:
– Faster than message passing, as messagepassing
system’s are implemented using system calls and
thus require the more time-consuming task
– Once shared memory is established, all accesses are
treated as routine memory accesses
8
Interprocess Communication
Shared Memory Method
• Processes frequently need to communicate
with other processes.
– For example, the output of the first process must
be passed to the second process
• There are three issues here.
1) How one process can pass information to
another.
2) Making sure two or more processes do not get in
each other's way. no conflicts or deadlock.
3) Proper sequencing when dependencies are
present
9
Communication in threads
• The first one—passing information—is easy
for threads since they share a common address
space
• However, the other two—keeping out of each
other's hair and proper sequencing—apply
equally well to threads.
• The same problems exist and the same
solutions apply.
• We will discuss about processes but remember
it equally applies for threads
10
Interprocess Communication
Shared Memory Model
• Processes may share some common storage
that each one can read and write.
• The shared storage may be:
– in main memory (possibly in a kernel data
structure)
– a shared file
• The location of the shared memory does not
change the nature of the communication or the
problems that arise.
11
Interprocess Communication
Example – A print spooler
• When a process wants to print a file, it enters
the file name in a special spooler directory.
• Another process, the printer daemon,
periodically checks to see if there are any files
to be printed, and if there are, it prints them
and then removes their names from the
directory.
12
Interprocess Communication
Example – A print spooler
• Assumptions:
– The spooler directory has a very large number of
slots, numbered 0, 1, 2 each one capable of
holding a file name.
– There are two shared variables:
• out, which points to the next file to be printed
• in, which points to the next free slot in the directory.
• These two variables might well be kept on a
two-word file available to all processes.
13
Interprocess Communication
Example – A print spooler
• At a certain instant:
– slots 0 to 3 are empty (the files have already been
printed)
– slots 4 to 6 are full (with the names of files
queued for printing).
• More or less simultaneously, processes A and
B decide they want to queue a file for printing.
• This situation is shown diagrammatically in
next slide.
14
Interprocess Communication
Race Conditions
Two processes want to access shared memory at same time
15
Interprocess Communication
Example – A print spooler
• In the under discussion instant:
– Process A reads in and stores the value, 7, in a
local variable called next-free slot.
– Just then a clock interrupt occurs and the CPU
decides that process A has run long enough, so it
switches to process B.
– Process B also reads in, and also gets a 7.
– It too stores it in its local variable next-free slot.
• At this instant both processes think that the
next available slot is 7.
16
Interprocess Communication
Example – A print spooler
• Process B now continues to ran.
– It stores the name of its file in slot 7 and updates
in to be an 8.
– Then it goes off and does other things.
• Eventually, process A runs again, starting
from the place it left off.
– It looks at next_free slot, finds a 7 there, and
writes its file name in slot 7
– Then it computes next-free slot + 1, which is 8,
and sets in to 8.
17
Interprocess Communication
Example – A print spooler
• In the scenario under discussion:
– The spooler directory is now internally consistent
with the valued 8, so the printer daemon will not
notice anything wrong BUT process B will never
receive any output,
– User B will hang around the printer room wistfully
hoping for output that never comes.
• When two or more processes are reading or
writing some shared data and final result
depends on who runs precisely when, are
called race conditions.
18
Avoiding Race Conditions
• How do we avoid race conditions?
– find some way to prohibit more than one
process from reading and writing the shared
data at the same time.
• What we need is mutual exclusion:
– way of making sure that if one process is
using a shared variable or file, the other
processes will be excluded from doing the
same thing.
19
Avoiding Race Conditions
An abstract way
• Part of the time, a process is busy doing internal
computations and other things that do not lead to
race conditions.
• Sometimes a process has to access shared
memory or files, or do other critical things that
can lead to races.
• The part of the program where the shared
memory is accessed is called the critical region
or critical section.
• If we could arrange matters such that no two
processes were ever in their critical regions at
the same time, we could avoid races.
20
Critical Regions (1)
Four conditions to provide mutual exclusion
in the abstract way:
1.
2.
3.
4.
No two processes simultaneously in critical
region
No assumptions made about speeds or
numbers of CPUs
No process running outside its critical region
may block another process
No process must wait forever to enter its
critical region
21
Critical Regions (2)
Mutual exclusion using critical regions
22
Mutual Exclusion with Busy Waiting
Disabling Interrupts
• To achieve mutual exclusion:
– disable all interrupts just after entering its critical
region and re-enable them just before leaving it.
• With interrupts disabled, no clock interrupts
can occur.
• Thus, once a process has disabled interrupts, it
can examine and update the shared memory
without fear that any other process will
intervene.
23
Mutual Exclusion with Busy Waiting
Disabling Interrupts
• Unattractive approach
– Suppose that one of them did it, and never turned
them on again? That could be the end of the
system.
• In a multiprocessor (with two or possibly
more CPUs) disabling interrupts affects only
the CPU that executed the disable instruction.
The other ones will continue running and can
access the shared memory.
24
Mutual Exclusion with Busy Waiting
Lock Variables
• As a second attempt, let us look for a software
solution.
• Consider having a single, shared (lock)
variable, initially 0. When a process wants to
enter its critical region, it first tests the lock:
– If the lock is 0, the process sets it to 1 and enters
the critical region.
– If the lock is already 1, the process just waits until
it becomes 0.
25
Mutual Exclusion with Busy Waiting
Lock Variables
• It has the same fatal flaw of spooler directory.
– Suppose that one process reads the lock and sees
that it is 0.
– Before it can set the lock to 1, another process is
scheduled, runs, and sets the lock to 1.
– When the first process runs again, it will also set
the lock to 1, and two processes will be in their
critical regions at the same time.
26
Interprocess Communication
Message-Passing Systems
• Message passing provides is particularly
useful in a distributed environment, having no
shared address space.
• For example, a chat program used on the
World Wide Web could be designed so that
chat participants communicate with one
another by exchanging messages.
27
Interprocess Communication
Message-Passing Systems
• Message passing provides is particularly
useful in a distributed environment, having no
shared address space.
• For example, a chat program used on the
World Wide Web could be designed so that
chat participants communicate with one
another by exchanging messages.
• A message-passing facility provides at least
two operations: send(message) and
receive(message).
28
Interprocess Communication
Message-Passing Systems
• Messages sent by a process can be:
– fixed sized
– variable size
• In fixed-sized messages, the system-level
implementation is straightforward.
– This restriction, makes the task of programming
more difficult.
• Variable-sized messages require a more
complex system-level implementation
– The programming task becomes simpler.
29
Interprocess Communication
Message-Passing Systems
• If processes P and Q want to communicate, a
communication link must exist between them.
• This link can be implemented in different ways.
• Here are several methods for logically
implementing a link and the
send()/receive() operations:
1. Direct or indirect communication
2. Synchronous or asynchronous communication
3. Automatic or explicit buffering
30
Interprocess Communication
Direct Communication
• Under direct communication, each process that
wants to communicate must explicitly name the
recipient or sender of the communication.
• In this scheme, the send() and receive()
primitives are defined as:
– send(P, message)
//Send a message to process P.
– receive(Q, message)
//Receive a message from process Q.
31
Interprocess Communication
Direct Communication
• A communication link in this scheme has the
following properties:
1. A link is established automatically between every
pair of processes that want to communicate.
 The processes need to know only each other's identity to
communicate.
2. A link is associated with exactly two processes.
3. Between each pair of processes, there exists exactly
one link.
32
Interprocess Communication
symmetry/asymmetry addressing schemes
• This scheme exhibits symmetry in addressing:
– both the sender process and the receiver process must
name the other to communicate.
• A variant of this is asymmetry in addressing:
– only the sender names the recipient; the recipient is
not required to name the sender.
– In this scheme, two primitives are defined as follows:
• send(P, message)
• receive (id, message)
– the variable id is set to the name of the process with
which communication has taken place.
33
Interprocess Communication
symmetry/asymmetry addressing schemes
• The disadvantage in both of these schemes is the
limited modularity of the resulting process
definitions.
– Changing the identifier of a process may necessitate
examining all other process definitions.
– All references to the old identifier must be found, so
that they can be modified to the new identifier.
• In general, any such hard-coding techniques,
where identifiers must be explicitly stated, are
less desirable than techniques involving
indirection
34
Interprocess Communication
Indirect Communication
• The messages are sent to and received from
mailboxes, or ports.
– A mailbox can be viewed abstractly as an object into
which messages can be placed by processes and from
which messages can be removed.
• Each mailbox has a unique identification.
– For example, POSIX message queues use an integer
value to identify a mailbox.
• In this scheme, a process can communicate with
some other process via a number of different
mailboxes.
35
Interprocess Communication
Indirect Communication
• Two processes can communicate only if the
processes have a shared mailbox
• The send() and receive 0 primitives are
defined as follows:
– send (A, message)
//Send a message to mailbox A.
– receive (A, message)
//Receive a message from mailbox A.
36
Interprocess Communication
Indirect Communication
• In this scheme, a communication link has the
following properties:
– A link is established between a pair of processes only
if both members of the pair have a shared mailbox.
– A link may be associated with more than two
processes.
– Between each pair of communicating processes, there
may be a number of different links, with each link
corresponding to one mailbox.
37
Interprocess Communication
Indirect Communication
• Now suppose that processes P1, P2, and P3 all share mailbox A.
• Process P1 sends a message to A, while both P2 and P3 execute
a receive()from A.
• Which process will receive the message sent by P1?
• The answer depends on which of the following methods we
choose:
– Allow a link to be associated with two processes at most.
– Allow at most one process at a time to execute a receive()
operation.
– Allow the system to select arbitrarily which process will receive
the message (that is, either P2 or P3, but not both, will receive the
message).
38
Interprocess Communication
Indirect Communication
• A mailbox may be owned by:
– a process
– the operating system
• If the mailbox is owned by a process (that is, the mailbox
is part of the address space of the process), then we
distinguish between:
– the owner (which can only receive messages through this
mailbox)
– the user (which can only send messages to the mailbox).
• Since each mailbox has a unique owner, there can be no
confusion about which process should receive a message
sent to this mailbox.
39
Interprocess Communication
Indirect Communication
• A mailbox that is owned by the operating system
has an existence of its own.
– It is independent and is not attached to any particular
process.
• The operating system then must provide a
mechanism that allows a process to do the
following:
1. Create a new mailbox.
2. Send and receive messages through the mailbox.
3. Delete a mailbox.
40
Interprocess Communication
Synchronous and Asynchronous Communication
• Message passing may be:
– blocking or nonblocking also known as synchronous and
asynchronous.
• Blocking send.
– The sending process is blocked until the message is received
by the receiving process or by the mailbox.
• Nonblocking send.
– The sending process sends the message and resumes operation.
• Blocking receive.
– The receiver blocks until a message is available.
• Nonblocking receive.
– The receiver retrieves either a valid message or a null.
41
Interprocess Communication
Synchronous and Asynchronous Communication
• Different combinations of send() and receive()
are possible.
– When both send() and receive() are blocking, we have
a appointments between the sender and the receiver.
• Solution to the producer-consumer problem becomes
insignificant when we use blocking send() and
receive() statements.
– Producer invokes the blocking send() call and waits until
the message is delivered to either the receiver or the mailbox.
– Likewise, when the consumer invokes receive(), it blocks until
a message is available.
• The concepts of synchronous and asynchronous occur
frequently in operating-system I/0 algorithms
42
Interprocess Communication
Automatic or explicit buffering
• Whether communication is direct or indirect, messages
exchanged by communicating processes reside in a
temporary queue.
• Such queues can be implemented in three ways:
1. Zero capacity.
• The queue has a maximum length of zero; thus, the link cannot have
any messages waiting in it.
• In this case, the sender must block until the recipient receives the
message.
2. Bounded capacity.
• The queue has finite length n; thus, at most n messages can reside in it.
• If queue is not full when a new message is sent, the message is placed in
the queue, and the sender can continue execution without waiting.
• If link is full, the sender must block until space is available in the queue.
43
Interprocess Communication
Automatic or explicit buffering
3. Unbounded capacity.
• The queue's length is potentially infinite; thus, any number of messages
can wait in it.
• The sender never blocks.
• The zero-capacity case is sometimes referred to as a
message system with no buffering; the other cases are
referred to as systems with automatic buffering.
44