comp5102 lecture 4 operating systems (os) inter-process communication phones off (please)

COMP5102 Lecture 4

Operating Systems (OS)

Inter-process Communication

phones off (please)

© De Montfort University, 2004 Comp5102 - L4 2

Lecture Outline • Interprocess synchronisation

• Shared Resources– race conditions

– deadlocks

– Starvation

• Access control– Sleep and Wakeup

– Semaphore

• Unix signals


Inter-process Communication (IPC)

• Processes need to communicate. We can split them into two types :-

• single processor IPC

multiprocessor IPC / \

/ \ • Distributed systems Multi-CPU systems (Networked) (Shared bus)


Synchronisation

• Co-existence of processes within a system • One process generate data, the other

receives it,– i.e. producer/consumer

• The need to synchronise – In a loop

– Producer generate some data– Consumer reads the data

• Handshaking required, as in hardware with I/O devices


Peer to Peer model

• Process A Process B• send message receive message

• receive message send message


client/server model

• Client Server• loop• send message wait for message• receive message send message• end loop• Note server runs continuously in a loop. Client runs then finishes. • UNIX servers called daemons, e.g.

– Clients telnet, ftp …– Sever daemons are telnetd, ftpd, …


Shared Resources

• Processes need to share resources– physical resources

• processor, memory, I/O devices, disks, etc.

– logical resources• data items such as message queues, data structures, etc.

• Resources can be classified as– reusable

– processor, memory, etc.

– consumable• transient data item or signal

– a message sent between one process and another


Shared Memory

• The most efficient IPC mechanism:

Process A Process AShared Memory

•uncontrolled access results in race conditions


Example …

• Consider, A is a producer, and B is a consumer.

• Process A is putting data into a buffer (the shared memory), process B is removing it.

• To control access we have a shared variable called ItIsFree, which is true when no process is accessing the buffer.


processes might look like :-

• Process A Process B• LOOP LOOP• IF ItIsFree then IF ItIsFree then• ItIsFree := FALSE ItIsFree := FALSE• put data in buffer take data from buffer• ItIsFree := TRUE ItIsFree := TRUE• END END• END END


Problems can occur..

• If testing and setting ItIsFree is not a single operation, i.e. NOT ATOMIC, e.g.:

• Process A Process B | | does test - ItIsFree is TRUE does test - ItIsFree is TRUE

• set ItIsFree FALSE set ItIsFree FALSE • now both accessing the buffer at the same time


Synchronisation Problems

• race conditions• two or more processes competing for a shared resource• the result varies according to the order of process execution

• deadlocks

• a situation where two or more processes are each waiting for resources held by others.

• starvation – indefinite blocking. • a process never gets access to a required resource


Race conditions prevention

• The section of code which accesses the shared memory is called the critical section.

• To ensure race conditions cannot occur we need mutual exclusion - only one process is in its critical section at a time.


To totally avoid race conditions:

• No two processes simultaneously in their critical sections.

• No assumption should be made about speed or number of CPU's.

• Processes outside their critical region should not be able to block other processes.

• No process should have to wait forever to enter its critical section.


Resource Classification

• Resources come in two main types– pre-emptable resources

• such a resource can be temporarily taken away from the process owning it with no ill effects

– e.g. processor, memory

– non-preemptable resources• once allocated to a process, removing such a resource (even

temporarily) could cause the computation to fail– e.g. printers

• Deadlocks occur with non-preemptable resources– pre-emptable resources can be reallocated to avoid DL


Deadlocks

• All operating systems have the ability to grant (temporary) exclusive access to certain resources

– suppose there are two processes, A and B, and two shared resources, printer and tape

• A allocates the printer• B allocates the tape

– then• A requests the tape and blocks until B releases it

– and then• B requests the printer and blocks until A releases it

– both processes block forever - this is a deadlock


Deadlock Characterization

• Mutual exclusion: only one process at a time can use a resource.

• Hold and wait: a process holding at least one resource is waiting to acquire additional resources held by other processes.

• No preemption: a resource can be released only voluntarily by the process holding it, after that process has completed its task.

Deadlock can arise if four conditions hold simultaneously.


Deadlock Characterization …

• Circular wait: there exists a set {P0, P1, …, P0} of waiting processes such that P0 is waiting for a resource that is held by P1, P1 is waiting for a resource that is held by P2, …, Pn–1 is waiting for a resource that is held by Pn, and P0 is waiting for a resource that is held by P1….


Deadlock Prevention

• Mutual Exclusion – not required for sharable resources.

• Hold and Wait – must guarantee that whenever a process requests a resource, it does not hold any other resources.– Low resource utilization; starvation possible.

Restrain the ways request can be made.


Deadlock Prevention (Cont.)

• No Preemption –– If a process that is holding some resources requests

another resource that cannot be immediately allocated to it, then all resources currently being held are released.

• Circular Wait – impose a total ordering of all resource types, and require that each process requests resources in an increasing order of enumeration.


Access control - Sleep and Wakeup

• The system calls:• sleep send process to sleep• wakeup wake process up.

– (i.e. make it ready to run)

• Procedure:– producer produces some output, it wakes the

consumer and goes to sleep itself – consumer consumes the input, wakes the producer

and sends itself to sleep.


Wakeups can get lost…

• Example:• the producer reads the flag and finds it zero• but before it can go to sleep the consumer is

scheduled• the consumer sends a wakeup, which gets

lost, since nothing is asleep yet• the consumer then goes to sleep, waiting for the

producer to wake it• the producer resumes and completes its sleep

operation. • Both then sleep forever.


Access control - Semaphores

• A semaphore is a cardinal variable, with an associated list of sleeping processes, plus two atomic operations which can be performed on it

• Operations are system calls, DOWN(s) and UP(s)

• Semaphores are only used to enable processes to synchronise themselves.


Semaphore Definition:-

• DOWN(s): If s = 0 then• send process to sleep• else• decrement s• Endif• UP(s): If any processes asleep on s then• wake one (i.e. make it ready to run)• else• increment s• Endif


UNIX Signals

• UNIX uses signals for IPC synchronisation

• A UNIX signal is similar to a software interrupt– a process may send a signal to another process– when a signal arrives, the receiving process stops

what it is doing and immediately services the signal

• A signal is sent by using the kill system callkill(process_id, signal_number);


Signals …

• The action taken when a signal is received by a process is specified by the signal system call

– it can (usually) be ignored– it can terminate the process– it can be ‘caught’ by a special signal handling function


Signal List

Signal Name Cause Signal Name Cause

SIGHUPhangup on controlling terminal

or death of control process

SIGINTinterrupt from keyboard

(usually CTRL-C)

SIGQUITquit from keyboard(usually CTRL-\)

SIGILL illegal instruction

SIGABRT abort signal from debugger

SIGFPE floating point exception

SIGKILLkill signal

(cannot be caught or ignored)

SIGSEGV segmentation violation

SIGPIPEbroken pipe: write to pipe

with no readers

SIGALRMtimer signal from alarm

system call

SIGCHLDchild process stopped

or terminated

SIGTERMused to request that a process

terminates gracefully

SIGUSR1 user-defined signal 1

SIGUSR2 user-defined signal 2

SIGPWR power failure

SIGWINCH window resize signal


Signal Examples

SIGKILL sent to a process to immediately kill it• this signal cannot be caught or ignored• typically used by the system to stop processes at

shutdown or by root to kill runaway processes via the ‘kill’ command

SIGFPE floating point error

SIGSEGV illegal or invalid memory reference• these can be caught by a program, to take appropriate

action


Signal ….

SIGPIPE write on a pipe with no readers• can be caught to allow the ‘earlier’ processes in

a pipe-line to exit when a ‘later’ process has exited abnormally

SIGINT/QUIT two levels of keyboard interrupt• SIGINT is ‘gentler’: interpreted as a request to

stop • SIGQUIT is ‘harder’: an instruction to stop


Effect of a signal on a process

• A program should be terminated, either normally exit executed, or abnormally - abort executed, depending on the signal received.

• Other options :-• ignore the signal; the arrival of the signal has no

effect.

• catch the signal; an exception routine called.


To ignore or catch a signal

• A system call signal is used.

• e.g. to ignore signals :-

• #include <signal.h>

• signal(SIGINT, SIG_IGN); /* to ignore SIGINT */

• signal(SIGINT, SIG_DFL); /* to change back to default */

comp5102 lecture 4 operating systems (os) inter-process communication phones off (please)

Documents

montfort university

message slide

process b loop

buffer itisfree

true itisfree

false itisfree

shared bus slide

time slide