SYNCHRONIZATION-2 Slides from: Computer Systems: A Programmer's Perspective, 2nd Edition by...

SYNCHRONIZATION-2Slides from:

Computer Systems: A Programmer's Perspective, 2nd Edition

by Randal E. Bryant and David R. O'Hallaron, Pren-tice Hall, 2011.

Last Lecture

Sharing Synchronization

Critical Sections and Unsafe Regions

Def: A trajectory is safe iff it does not enter any unsafe region

Claim: A trajectory is correct (wrt cnt) iff it is safe

H1 L1 U1 S1 T1

H2

L2

U2

S2

T2

Thread 1

Thread 2

critical section wrt cnt

critical sec-tion wrt cnt

Unsafe region

unsafe

safe

Enforcing Mutual Exclusion

Question: How can we guarantee a safe trajectory?

Answer: We must synchronize the execution of the threads so that they never have an unsafe trajectory. i.e., need to guarantee mutually exclusive access to crit-

ical regions

Classic solution: Semaphores (Edsger Dijkstra)

Other approaches (out of our scope) Mutex and condition variables (Pthreads) Monitors (Java)

Semaphores

Semaphore: non-negative global integer synchronization variable

Manipulated by P and V operations: P(s): [ while (s == 0) wait(); s--; ]

Dutch for "Proberen" (test) V(s): [ s++; ]

Dutch for "Verhogen" (increment)

OS kernel guarantees that operations between brackets [ ] are executed indivisibly

Only one P or V operation at a time can modify s. When while loop in P terminates, only that P can decrement s

Semaphore invariant: (s >= 0)

goodcnt.c: Proper Synchronization

Define and initialize a mutex for the shared variable cnt:

volatile int cnt = 0; /* Counter */ sem_t mutex; /* Semaphore that protects cnt */

Sem_init(&mutex, 0, 1); /* mutex = 1 */

Surround critical section with P and V:

for (i = 0; i < niters; i++) { P(&mutex); cnt++; V(&mutex); }

linux> ./goodcnt 10000OK cnt=20000linux> ./goodcnt 10000OK cnt=20000linux>

Warning: It’s much slower than badcnt.c.

Today

Producer-consumer problem Readers-writers problem Thread safety Races Deadlocks

Example: a producer-consumer problem

N buffers, counter (# of full buffers, 0 as initial value) Producer: produces a new buffer, increments counter Consumer: consumes a buffer, decrements counter

http://pages.cs.wisc.edu/~remzi/OSTEP/threads-cv.pdf

8

producerthread

sharedbuffer

consumerthread

Producer-Consumer Problem

Examples Multimedia processing:

Producer creates MPEG video frames, consumer renders them

Event-driven graphical user interfaces Producer detects mouse clicks, mouse movements, and

keyboard hits and inserts corresponding events in buffer Consumer retrieves events from buffer and paints the dis-

play

producerthread

sharedbuffer

consumerthread

Producer

while (true) { item * next_produced = produce();

// do nothing if buffers full

while (counter == BUFFER_SIZE) ;

buffer[in] = next_produced;

in = (in + 1) % BUFFER_SIZE;

counter++;

}

10

while (true) {

item* next_consumed;

// do nothing if no avail buff

while (counter == 0);

next_consumed = buffer[out];

out = (out + 1) % BUFFER_SIZE;

counter--;

consume(next_consumed);

}

Producer / Consumer

Consumer

Producer

while (true) { item * next_produced = produce();

// do nothing if buffers full

mutex_lock(&mutex);

while (counter == BUFFER_SIZE) {

mutex_unlock(&mutex);

process_yield(); // unlock and yield

mutex_lock (&mutex);

}

buffer[in] = next_produced;

in = (in + 1) % BUFFER_SIZE;

counter++;

mutex_unlock(&mutex);

}

11 while (true) {

item* next_consumed;

// do nothing if no avail buff

mutex_lock(&mutex);

while (counter == 0) {

mutex_unlock(&mutex);

process_yield();

mutex_lock (&mutex);

}

next_consumed = buffer[out];

out = (out + 1) % BUFFER_SIZE;

counter--;

mutex_unlock(&mutex);

consume(next_consumed);

}

Improved Producer / Consumer Consumer

Condition Variables

Problem: sometimes you want to wait until a condition happens.

E.g., wait for a child to finish (often called a join())

Condition variable

A condition variable is an explicit queue that threads can put themselves on when some state of execution (i.e., some condition) is not as desired.

That is you wait on the condition. Some other threads, when it changes the state can

then wake on (or more) of the waiting threads

Condition Variables Condition variables is a synchronization primitive that

helps us model events. A condition variable represents some condition that a

thread can: Wait on, until the condition occurs; or Notify other waiting threads that the condition has occur

It provides a place to wait (queue).

Condition Variables

Operations on condition variables: wait() -- Block until another thread calls signal() or broadcast() on the

CV signal() -- Wake up one thread waiting on the CV broadcast() -- Wake up all threads waiting on the CV

Pthread pthread_cond_wait(pthread_cond_t *c, pthread_mutex_t *m); pthread_cond_signal(pthread_cond_t *c); pthread_cond_broadcast (pthread_cond_t *c);

Used with mutex

int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mu-tex);

int pthread_cond_timedwait(pthread_cond_t *cond, pthread_mutex_t *mutex, const struct timespec *abstime);

The pthread_cond_wait() and pthread_cond_timedwait() functions are used to block on a condition variable. They are called with mutex locked by the calling thread or undefined behaviour will result.

These functions atomically release mutex and cause the calling thread to block on the condition variable cond;

Broadcast

The pthread_cond_broadcast() function is used when-ever the shared-variable state has been changed in a way that more than one thread can proceed with its task.

Single producer/multiple consumer problem The producer would notify all consumers that might be wait-

ing; more throughput on a multi-processor. Read-write lock.

Wakes up all waiting readers when a writer releases its lock. Recommended readinghttp://pages.cs.wisc.edu/~remzi/OSFEP/threads-cv.pdf

The pthread_cond_signal() call unblocks at least one of the threads that are blocked on the specified condition variable cond (if any threads are blocked on cond).

The pthread_cond_broadcast() call unblocks all threads currently blocked on the specified condition variable cond.

If more than one thread is blocked on a condition vari-able, the scheduling policy determines the order in which threads are unblocked.

Consume data

No data – wait()

C should have woken P!

Final version: Producer and consumer

Generalized to MAX items Important to use while statement to check the condition after wak-

ing up. It handles spurious wakeup.

cond_t empty, fill; mutex_t mutex;

void produce(int item) { pthread_mutex_lock(&mutex); while (count == MAX) pthread_cond_wait(&empty, &mutex); put(item); // put an item in the circular buffer pthread_cond_signal(&fill); // signal an item is filled ptherad_mutex_unlock(&mutex);}

int consumer() { pthread_mutex_lock(&mutex); while (count == 0) pthread_cond_wait(&fill, &mutex); int item = get(); pthread_cond_signal(&empty); pthread_mutex_unlock(&mutex); return item;}

Use two condition variables!

Barrier Synchronization

A wait at a barrier causes a thread to wait until all threads have performed a wait at the barrier.

At that point, they all proceed.

Implementing Barriers in Pthreads

Count the number of arrivals at the barrier. Wait if this is not the last arrival. Make everyone unblock if this is the last arrival. Since the arrival count is a shared variable, enclose the

whole operation in a mutex lock-unlock.

Implementing Barriers in Pthreads

void barrier(){

pthread_mutex_lock(&mutex_arr);arrived++;if (arrived<N) {

pthread_cond_wait(&cond, &mutex_arr);}else {

pthread_cond_broadcast(&cond); arrived=0; /* be prepared for next barrier */ }

pthread_mutex_unlock(&mutex_arr);}

Case Study: Prethreaded Concurrent Server

Masterthread Buffer ...

Acceptconnections

Insertdescriptors Remove

descriptors

Workerthread

Workerthread

Client

Client

...

Service client

Service client

Pool of worker

threads

Today

Producer-consumer problem Readers-writers problem Thread safety Races Deadlocks

Readers-Writers Problem

Generalization of the mutual exclusion problem

Problem statement: Reader threads only read the object Writer threads modify the object Writers must have exclusive access to the object Unlimited number of readers can access the object

Occurs frequently in real systems, e.g., Online airline reservation system Multithreaded caching Web proxy

Solution to First Readers-Writers Problem using mutex

int readcnt; /* Initially 0 */sem_t mutex, w; /* Both initially 1 */

void reader(void) { while (1) { P(&mutex); readcnt++; if (readcnt == 1) /* First in */ P(&w); V(&mutex);

/* Reading happens here */

P(&mutex); readcnt--; if (readcnt == 0) /* Last out */ V(&w); V(&mutex); }}

void writer(void) { while (1) { P(&w);

/* Writing here */

V(&w); }}

Readers:

Writers rw1.c

Pthread provides read/write lock

pthread_rwlock_init()

pthread_rwlock_rdlock() pthread_rwlock_wrlock()

Reader Writer

Reader OK No

Writer No No

Access permission table

Today

Producer-consumer problem Readers-writers problem Thread safety Races Deadlocks

Crucial concept: Thread Safety

Functions called from a thread must be thread-safe

Def: A function is thread-safe iff it will always produce correct results when called repeatedly from multiple concurrent threads.

Classes of thread-unsafe functions: Class 1: Functions that do not protect shared variables. Class 2: Functions that keep state across multiple invocations. Class 3: Functions that return a pointer to a static variable. Class 4: Functions that call thread-unsafe functions.

Thread-Unsafe Functions (Class 1)

Failing to protect shared variables Fix: Use P and V semaphore operations Example: goodcnt.c Issue: Synchronization operations will slow down code

Thread-Unsafe Functions (Class 2)

Relying on persistent state across multiple function invocations Example: Random number generator that relies on

static state static unsigned int next = 1;

/* rand: return pseudo-random integer on 0..32767 */ int rand(void) { next = next*1103515245 + 12345; return (unsigned int)(next/65536) % 32768; } /* srand: set seed for rand() */ void srand(unsigned int seed) { next = seed; }

Thread-Safe Random Number Generator

Pass state as part of argument and, thereby, eliminate static state

Consequence: programmer using rand_r must main-tain seed

/* rand_r - return pseudo-random integer on 0..32767 */ int rand_r(int *nextp) { *nextp = *nextp*1103515245 + 12345; return (unsigned int)(*nextp/65536) % 32768; }

Thread-Unsafe Functions (Class 3)

Returning a pointer to a static vari-able

Fix 1. Rewrite function so caller passes address of variable to store result Requires changes in caller and callee

Fix 2. Lock-and-copy Requires simple changes in caller (and

none in callee) However, caller must free memory.

/* lock-and-copy version */char *ctime_ts(const time_t *timep, char *privatep){ char *sharedp;

P(&mutex); sharedp = ctime(timep); strcpy(privatep, sharedp); V(&mutex); return privatep;}

Warning: Some functions like gethost-byname require a deep copy. Use reen-trant gethostbyname_r version instead.

Thread-Unsafe Functions (Class 4)

Calling thread-unsafe functions Calling one thread-unsafe function makes the en-

tire function that calls it thread-unsafe

Fix: Modify the function so it calls only thread-safe functions

Reentrant Functions

Def: A function is reentrant iff it accesses no shared vari-ables when called by multiple threads. Important subset of thread-safe functions.

Require no synchronization operations. Only way to make a Class 2 function thread-safe is to make it reen-

trant (e.g., rand_r ) Reentrant function has a property that it can be interrupted in the

middle of its execution and then safely called again.

Reentrantfunctions

All functions

Thread-unsafefunctions

Thread-safefunctions

Thread-Safe Library Functions

All functions in the Standard C Library (at the back of your K&R text) are thread-safe Examples: malloc, free, printf, scanf

Most Unix system calls are thread-safe, with a few ex-ceptions:Thread-unsafe function Class Reentrant version

asctime 3 asctime_rctime 3 ctime_rgethostbyaddr 3 gethostbyaddr_rgethostbyname 3 gethostbyname_rinet_ntoa 3 (none)localtime 3 localtime_rrand 2 rand_r