You are on page 1of 11

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

 Generally available as assembly-language instructions.


 Languages defined to replace assembly language for systems
programming allow system calls to be made directly (e.g., C. Bliss,
PL/360)
Three general methods are used to pass parameters between a running program and
the operating system.
 Pass parameters in registers.
 Store the parameters in a table in memory, and the table address is
passed as a parameter in a register.
 Push (store) the parameters onto the stack by the program, and pop off
the stack by operating system.

SYSTEM CALL IN OPERATING SYSTEMS


System Call Mechanism:

 User code can be arbitrary


 User code cannot modify kernel memory
 Makes a system call with parameters
 The call mechanism switches code to kernel mode
 Execute system call
 Return with results

Categories of System Call:


The system call is made using the system call machine language
instructions. System calls can be grouped into five major catagories
 Process management
 Memory management
 File management
 Device management
 Communication
This functions are used to load, execute, create process, terminate process, get/set
process attributes, wait for time, wait event, signal event, allocate, free memory.
This functions are used to create file, delete file, open, close, read, write,
reposition, get/set file attributes.

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.

Communication functions are used to create, delete communication connection,


send, receive messages, transfer status information, attach or detach remote devices

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.

In simple words “InterProcess Communication” means Mechanism for processes to


communicate and to synchronize their actions.

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

Implementation of communication link


 physical (e.g., shared memory, hardware bus)
 logical (e.g., logical properties)

IPC MANAGEMENT

Purpose of IPC

 Data Transfer
 Sharing Data
 Event notification
 Resource Sharing and Synchronization
 Process Control

Main IPC Methods

Method Provided by (Operating systems or other environments)


File Most operating systems.
Most operating systems; some systems, such as Windows, only implement
Signal signals in the C run-time library and do not actually provide support for their use
as an IPC technique.
Socket Most operating systems.
Message queue Most operating systems.
Pipe All POSIX systems, Windows.
Named pipe All POSIX systems, Windows.
Semaphore All POSIX systems, Windows.
Shared memory All POSIX systems, Windows.
Message
passing
Used in MPI paradigm, Java RMI, CORBA, MSMQ, MailSlots and others.
(shared
nothing)
Memory- All POSIX systems, Windows. This technique may carry race condition risk if a
mapped file temporary file is used.

Message Passing System:


Exchange messages over a communication link
Methods for implementing the communication link and primitives (send/receive):
1. Direct or Indirect communications (Naming)
2. Symmetric or Asymmetric communications
3. Automatic or Explicit buffering
4. Send-by-copy or send-by-reference
5. fixed or variable sized messages

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.

INTERPROCESS COMMUNICATION IN LINUX:

You might also like