Assignment
Assignment
Operating Systems
II Year CSE B Sec
HARISH
1/18/2011
SYSTEM CALL
DEFINITION: The mechanism used by an application program to request service
from the operating system. System calls often use a special machine code
instruction which causes the processor to change mode (e.g. to "supervisor mode"
or "protected mode"). This allows the OS to perform restricted actions such as
accessing hardware devices or the memory management unit.
In simple word “System Call” defined as interface between a running program and
the operating system
This functions are used to request device, release device, read, write, reposition,
get/set device attributes, logically attach or detach devices.
Information Maintenance functions are used to get/set time or date, get/set system
data, get/set process, file, or device attributes.
INTERPROCESS COMMUNICATION
DEFINITON: Interprocess communication (IPC) is a set of programming
interfaces that allow a programmer to coordinate activities among different
program processes that can run concurrently in an operating system. This allows a
program to handle many user requests at the same time. Since even a single user
request may result in multiple processes running in the operating system on the
user's behalf, the processes need to communicate with each other. The IPC
interfaces make this possible. Each IPC method has its own advantages and
limitations so it is not unusual for a single program to use all of the IPC methods.
IPC MANAGEMENT
Purpose of IPC
Data Transfer
Sharing Data
Event notification
Resource Sharing and Synchronization
Process Control
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.
– Link may be unidirectional or bi-directional.
• Operations
– create a new mailbox
– send and receive messages through mailbox
– destroy a mailbox
• Mailbox sharing
– P1, P2, and P3 share mailbox A.
– P1, sends; P2 and P3 receive.
– Who gets the message?
• Solutions
– Allow a link to be associated with at most two processes.
– Allow only one process at a time to execute a receive operation.
– Allow the system to select arbitrarily the receiver. Sender is notified
who the receiver was.
Buffering:
Queue of messages attached to the link; implemented in one of three ways.
1. Zero capacity – 0 messages
Sender must wait for receiver (rendezvous).
2. Bounded capacity – finite length of n messages
Sender must wait if link full.
3. Unbounded capacity – infinite length
Sender never waits.
Synchronised:
send and receive operations blocking
»sender is suspended until receiving process does a
corresponding read
» receiver suspended until a message is sent for it to receive
properties :
» processes tightly synchronised - the rendezvous of Ada
» effective confirmation of receipt for sender
» aat most one message can be outstanding for any process pair
no buffer space problems
» easy to implement, with low overhead
disadvantages :
» sending process might want to continue after its send operation
without waiting for confirmation of receipt
» receiving process might want to do something else if no
message is waiting to be received
Asynchronous :
send and receive operations non-blocking
» sender continues when no corresponding receive outstanding
» receiver continues when no message has been sent
properties :
» messages need to be buffered until they are received
aamount of buffer space to allocate can be problematic
a process running amok could clog the system with
messages if not careful
» ooften very convenient rather than be forced to wait
particularly for senders
» can increase concurrency
» ssome awkward kernel decisions avoided
e.g. whether to swap a waiting process out to disc or not
receivers can poll for messages
» i.e. do a test-receive every so often to see if any messages
waiting
» interrupt and signal programming more difficult
» preferable alternative perhaps to have a blocking receive in a
separate thread
Other combinations :
non-blocking send + blocking receive
» probably the most useful combination
» sending process can send off several successive messages to
one or more processes if need be without being held up
» receivers wait until something to do i.e. take some action on
message receipt
e.g. a server process
might wait on a read until a service request arrived,
then transfer the execution of the request to a separate
thread
then go back and wait on the read for the next request
blocking send + non-blocking receive
» conceivable but probably not a useful combination.