0% found this document useful (0 votes)
5 views

OS Lecture3

Uploaded by

adiasaraf29
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
5 views

OS Lecture3

Uploaded by

adiasaraf29
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 24

LECTURE3

PROCESSES
Instructor: Dr.Fouzia Idrees
Interprocess Communication

 Processes within a system may be independent or cooperating


 Cooperating process can affect or be affected by other processes, including
sharing data
 Reasons for cooperating processes:
 Information sharing. Since several users may be interested in the same piece of
information (for instance, a shared file), we must provide an environment to allow
concurrent access to such information.
 Computation speedup. If we want a particular task to run faster, we must break it
into subtasks, each of which will be executing in parallel with the others. Notice that
such a speedup can be achieved only if the computer has multiple processing cores.
 Modularity. We may want to construct the system in a modular fashion, dividing
the system functions into separate processes
 Convenience. Even an individual user may work on many tasks at the same time.
For instance, a user may be editing, listening to music, and compiling in parallel.
 Cooperating processes need interprocess
communication (IPC)
 Two models of IPC
 Shared memory
 Message passing
Cooperating Processes

 Shared memory
 In the shared-memory model, a region of memory that is shared
by cooperating processes is established. Processes can then
exchange information by reading and writing data to the share
region.
 Other processes that wish to communicate using this shared-
memory segment must attach it to their address space.
 Processes are also responsible for ensuring that they are not
writing to the same location simultaneously.
 To understand the concept of cooperating processes lets
consider a producer-consumer problem.
 The producer process produces information that is
consumed by a consumer process. For example, a
compiler may produce assembly code that is
consumed by an assembler. The assembler, in turn,
may produce object modules/code that are consumed
by the loader.
 A web server produces (that is, provides) HTML files
and images, which are consumed (that is, read) by the
client web browser requesting the resource.
Producer-Consumer Problem

 One solution to the producer–consumer problem uses shared


memory. To allow producer and consumer processes to run
concurrently, we must have available a buffer of items that can be
filled by the producer and emptied by the consumer.
 This buffer will reside in a region of memory that is shared by the
producer and consumer processes. A producer can produce one
item while the consumer is consuming another item. The producer
and consumer must be synchronized, so that the consumer does
not try to consume an item that has not yet been produced.

 Unbounded-buffer places no practical limit on the size of the buffer


 Bounded-buffer assumes that there is a fixed buffer size
Interprocess Communication – Message Passing

 Mechanism for processes to communicate and to synchronize


their actions
 It is particularly useful in a distributed environment, where the
communicating processes may reside on different computers
connected by a network.

 IPC facility provides two operations:


 send(message) – message size fixed or variable
 receive(message)
 If P and Q wish to communicate, they need to:
 establish a communication link between them
 exchange messages via send/receive
Direct Communication
 Processes must name each other explicitly:
 send (P, message) – send a message to process P
 receive(Q, message) – receive a message from process Q

 Properties of communication link


 Links are established automatically
 A link is associated with exactly one pair of communicating
processes
 Between each pair there exists exactly one link
 The link may be unidirectional, but is usually bi-directional
Indirect Communication
 Messages are directed and received from mailboxes (also referred
to as ports)
 Each mailbox has a unique id
 Processes can communicate only if they share a mailbox

 Properties of communication link


 Link established only if processes share a common mailbox
 A link may be associated with many processes
 Each pair of processes may share several communication links
corresponding to one mail box
 Link may be unidirectional or bi-directional
Indirect Communication
 Operations
 create a new mailbox
 send and receive messages through mailbox
 destroy a mailbox

 Primitives are defined as:


send(A, message) – send a message to mailbox A
receive(A, message) – receive a message from mailbox A
Synchronization
 Message passing may be either blocking or non-blocking

 Blocking is considered synchronous


 Blocking send: The sending process is blocked until the message is
received by the receiving process or by the mailbox.
 Blocking receive has the receiver block until a message is available

 Non-blocking is considered asynchronous


 Non-blocking send has the sender send the message and continue
 Non-blocking receive has the receiver receive a valid message or
null
Buffering
 Queue of messages attached to the link; implemented in
one of three ways
1. Zero capacity – The queue has a maximum length of
zero, the sender must block until the recipient receives
the message.
2. Bounded capacity – finite length of n messages
Sender must wait if link full. If the link is full, the
sender must block until space is available in the queue
3. Unbounded capacity – infinite length
Sender never waits
Examples of IPC Systems – Windows XP

 Message-passing centric via local procedure call (LPC)


facility
 Uses ports (like mailboxes) to establish and maintain
communication channels
 Communication works as follows:
 The client opens a handle to the subsystem’s connection port object.
 The client sends a connection request.
 The server creates two private communication ports and returns the
handle to one of them to the client.
 The client and server use the corresponding port handle to send
messages or callbacks and to listen for replies.
Local Procedure Calls in Windows XP
Communications in Client-Server Systems

 Sockets

 Remote Procedure Calls

 Pipes
Sockets
 A socket is defined as an endpoint for
communication
 A pair of processes communicating over a network
employs a pair of sockets—one for each process.
 sockets use a client–server architecture.
 A socket is identified by an IP address concatenated
with a port number
 The socket 161.25.19.8:1625 refers to port 1625 on
host 161.25.19.8
 Communication consists between a pair of sockets
Socket Communication
Remote Procedure Calls
 Remote procedure call (RPC) abstracts procedure calls
between processes on networked systems
 An RPC is initiated by the client, which sends a request
message to a known remote server to execute a specified
procedure with supplied parameters.
 The remote server sends a response to the client, and the
application continues its process. While the server is
processing the call, the client is blocked (it waits until the
server has finished processing before resuming execution),
unless the client sends an asynchronous request to the server.
 Stubs – client-side proxy for the actual procedure on
the server

 The client-side stub locates the server and Marshalls


the parameters

 The server-side stub receives this message, unpacks the


marshalled parameters, and performs the procedure on
the server
Pipes
 A pipe acts as a channel allowing two processes to communicate.
 Pipes were one of the first IPC mechanisms in early UNIX systems.
 They typically provide one of the simpler ways for processes to
communicate with one another

 Issues
 Is communication unidirectional or bidirectional?
 In the case of two-way communication, is it half or full-duplex?
 Must there exist a relationship (i.e. parent-child) between the
communicating processes?
 Can the pipes be used over a network?
Ordinary Pipes
 Ordinary Pipes allow communication in standard producer-
consumer style

 Producer writes to one end (the write-end of the pipe)

 Consumer reads from the other end (the read-end of the pipe)

 Ordinary pipes are therefore unidirectional

 Require parent-child relationship between communicating


processes
Named Pipes
 Named Pipes are more powerful than ordinary pipes

 Communication is bidirectional

 No parent-child relationship is necessary between the


communicating processes

 Several processes can use the named pipe for communication

 Provided on both UNIX and Windows systems


End of Lecture

You might also like