operating systems cmpsc 473 signals, introduction to mutual exclusion september 28, 2010 - lecture 9...

Operating SystemsCMPSC 473

Signals, Introduction to mutual exclusion

September 28, 2010 - Lecture 9

Instructor: Bhuvan Urgaonkar

Today• Inter-process communication

– Signals• Start discussion on process synchronization– Mutual exclusion problem

• Project 2: Multi-threaded programming using pthreads out– Deadline: Oct 19

Inter-process Communication

• Two forms of communication

– Message passing• E.g., signals, interrupts, traps, emails, HTTP requests, …

• We will study signals

– Shared memory• E.g., pipes, more general shared buffers, distributed shared memory

System calls related to signals

• kill(signal_num, pid) - to send a signal

• signal(signal_num, handler) - to handle it

Signal Handling (more)• When does a process handle a signal?

– Whenever it gets scheduled next after the generation of the signal

• We said the OS marks some members of the PCB to indicate that a signal is due– And we said the process will execute the signal handler when it gets scheduled

– But its PC had some other address! • The address of the instruction the process was executing when it was scheduled last

– Complex task due to the need to juggle stacks carefully while switching between user and kernel mode

Signal Handling (more)• Remember that signal handlers are

functions defined by processes and included in the user mode code segment– Executed in user mode in the process’s context

• The OS forces the handler’s starting address into the program counter – The user mode stack is modified by the OS so that the process execution starts at the signal handler

• setup_frame: sets up the user-mode stack– Forces Signal handler’s address into PC and some “return code”– After the handler is done, this return code gets executed

• It makes a system call such as sigreturn (in Linux) that does the following:

– 1. Copies the hardware context of the normal program to KM Stack– 2. Restores the User mode stack to its original state

• When the system call terminates, the normal program execution can continue

User mode Kernel mode

Normal program flowdo_signal( )

handle_signal( )setup_frame( )

Signal handler

Return code on the stack

system_call( )sys_sigreturn( )

restore_sigcontext( )

. . . (e.g., interrupt handling)

Signal Handling with Threads

• Recall: Signals are used in UNIX systems to notify a process that a particular event has occurred

• Recall: A signal handler is used to process signals- Signal is generated by particular event- Signal is delivered to a process- Signal is handled

• Options:– Deliver the signal to the thread to which the signal

applies– Deliver the signal to every thread in the process– Deliver the signal to certain threads in the process– Assign a specific thread to receive all signals for

the process

Signal Handling (Visual)

time

Signal due indicatorsSignal is not due

Signal is due

Timer interruptSystem call (trap)Calls kill() to

send a signal to P (trap)

Accesses illegalmemory location (trap)

Runs SIGSEGV handler; dumps core and exits

PCB of P

ISR run; assumeP scheduled again

Sys call done; assume Par scheduled

Timer interrupt

PParent of P

These are the events that P sees (its view of what is going on)

Kernel

P’s signal handler runs

Sched choses P

The mutual exclusion problem

• We will study it in the context of the shared memory model

Example: Producer and Consumer

while (true) { /* produce an item and put in

nextProduced */ while (count == BUFFER_SIZE); // do nothing

buffer [in] = nextProduced;

in = (in + 1) % BUFFER_SIZE;

count++;}

while (true) { while (count == 0); // do nothing

nextConsumed = buffer[out];

out = (out + 1) % BUFFER_SIZE; count--;

/* consume the item in nextConsumed}

Producer Consumer

• Shared variables: buffer and count• Local variables: in, out, nextProduced, nextConsumed

Race Condition• count++ could be implemented as

register1 = count register1 = register1 + 1 count = register1

• count-- could be implemented as register2 = count register2 = register2 - 1 count = register2

• Consider this execution interleaving with “count = 5” initially:

S0: producer executes register1 = count {register1 = 5}S1: producer executes register1 = register1 + 1 {register1 = 6} S2: consumer executes register2 = count {register2 = 5} S3: consumer executes register2 = register2 - 1 {register2 = 4} S4: producer executes count = register1 {count = 6 } S5: consumer executes count = register2 {count = 4}

Example: Producer and Consumer

while (true) { /* produce an item and put in

nextProduced */ while (count == BUFFER_SIZE); // do nothing

buffer [in] = nextProduced;

in = (in + 1) % BUFFER_SIZE;

count++;}

while (true) { while (count == 0); // do nothing

nextConsumed = buffer[out];

out = (out + 1) % BUFFER_SIZE; count--;

/* consume the item in nextConsumed}

Producer Consumer

• Shared variables: buffer and count• Local variables: in, out, nextProduced, nextConsumed• Important: Think how producer-consumer applies to P2

– Hint: Customer = Producer and Worker = Consumer

We would like these operationsto be mutually exclusive

What about buffer manipulation?

Mutual Exclusion• We want to use mutual exclusion to synchronize access

to shared data– Meaning: Only one thread can access a shared resource at a time

• Code that uses mutual exclusion to synchronize its execution is called a critical section– Only one thread at a time can execute code in the critical section

– All other threads are forced to wait on entry– When one thread leaves the critical section, another can enter

do { entry sectionCRITICAL SECTION exit sectionREMAINDER SECTION } while (TRUE);

Example to Show Mut. Excl. is Non-trivial• How about constructing a “lock” s.t. before getting into critical

section, we acquire it and after leaving critical section, we release it?

• Is there any trouble if we use a boolean flag as a lock? Consider P1 and P2 while (lock == 1) ; // Do nothing, just wait

//position 1 lock = 1; ..... ..... // Critical Section ..... lock = 0;• If P1 interrupted at position 1, race condition might occur• P1 was waiting until lock == 0. Before it announces its turn (i.e.,

sets lock = 1), suppose P2 gets scheduled and sees that lock is 0• Before P2 leaves its critical section (i.e., sets lock = 0), suppose

it gets descheduled• Since P1 was at position 1, it will set lock = 1 and also get into

its critical section• Now, two processes are in the critical section at the same time!

Doesn’t work!

Peterson’s Solution

• Two process solution• Assume that the LOAD and STORE instructions are

atomic; that is, cannot be interrupted.• The two processes share two variables:

– int turn; – Boolean flag[2]

• The variable turn indicates whose turn it is to enter the critical section.

• The flag array is used to indicate if a process is ready to enter the critical section. flag[i] = true implies that process Pi is ready

Algorithm for Process Piwhile (true) {

flag[i] = TRUE; turn = j; while ( flag[j] && turn == j);

CRITICAL SECTION

flag[i] = FALSE;

REMAINDER SECTION }