COMP5102 Lecture 4 Operating Systems (OS) Inter-process Communication phones off (please)

© De Montfort University, 2004Comp L42 Lecture Outline Interprocess synchronisation Shared Resources –race conditions –deadlocks –Starvation Access control –Sleep and Wakeup –Semaphore Unix signals

© De Montfort University, 2004Comp L43 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)

© De Montfort University, 2004Comp L44 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

© De Montfort University, 2004Comp L45 Peer to Peer model Process A Process B send message  receive message receive message  send message

© De Montfort University, 2004Comp L46 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, …

© De Montfort University, 2004Comp L47 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

© De Montfort University, 2004Comp L48 Shared Memory The most efficient IPC mechanism: Process A Shared Memory uncontrolled access results in race conditions

© De Montfort University, 2004Comp L49 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.

© De Montfort University, 2004Comp L410 processes might look like :- Process A Process B 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

© De Montfort University, 2004Comp L411 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 set ItIsFree FALSE set ItIsFree FALSE now both accessing the buffer at the same time

© De Montfort University, 2004Comp L412 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

© De Montfort University, 2004Comp L413 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.

© De Montfort University, 2004Comp L414 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.

© De Montfort University, 2004Comp L415 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

© De Montfort University, 2004Comp L416 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

© De Montfort University, 2004Comp L417 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.

© De Montfort University, 2004Comp L418 Deadlock Characterization … Circular wait: there exists a set {P 0, P 1, …, P 0 } of waiting processes such that P 0 is waiting for a resource that is held by P 1, P 1 is waiting for a resource that is held by P 2, …, P n–1 is waiting for a resource that is held by P n, and P 0 is waiting for a resource that is held by P 1….

© De Montfort University, 2004Comp L419 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.

© De Montfort University, 2004Comp L420 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.

© De Montfort University, 2004Comp L421 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.

© De Montfort University, 2004Comp L422 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.

© De Montfort University, 2004Comp L423 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.

© De Montfort University, 2004Comp L424 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

© De Montfort University, 2004Comp L425 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 call kill(process_id, signal_number);

© De Montfort University, 2004Comp L426 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

© De Montfort University, 2004Comp L427 Signal List Signal NameCauseSignal NameCause SIGHUP hangup on controlling terminal or death of control process SIGINT interrupt from keyboard (usually CTRL-C) SIGQUIT quit from keyboard (usually CTRL-\) SIGILL illegal instruction SIGABRT abort signal from debugger SIGFPE floating point exception SIGKILL kill signal (cannot be caught or ignored) SIGSEGV segmentation violation SIGPIPE broken pipe: write to pipe with no readers SIGALRM timer signal from alarm system call SIGCHLD child process stopped or terminated SIGTERM used to request that a process terminates gracefully SIGUSR1 user-defined signal 1 SIGUSR2 user-defined signal 2 SIGPWR power failure SIGWINCH window resize signal

© De Montfort University, 2004Comp L428 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

© De Montfort University, 2004Comp L429 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

© De Montfort University, 2004Comp L430 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.

© De Montfort University, 2004Comp L431 To ignore or catch a signal A system call signal is used. e.g. to ignore signals :- #include signal(SIGINT, SIG_IGN); /* to ignore SIGINT */ signal(SIGINT, SIG_DFL); /* to change back to default */