Computer Systems Principles Synchronization

UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science

Computer Systems PrinciplesSynchronization

Emery Berger and Mark CornerUniversity of Massachusetts

Amherst

UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science 2

Synchronization Threads must ensure consistency

– Else: race condition(non-deterministic result)

– Requires synchronization operations How to write concurrent code How to implement synch. operations


Synchronization – Motivation “The too much milk problem”

Model of need to synchronize activities


Synchronization Terminology Mutual exclusion (“mutex”)

– prevents multiple threads from entering Critical section

– code only one thread can execute at a time Lock

– mechanism for mutual exclusion– Lock entering critical section, accessing shared data– Unlock when complete– Wait if locked

Invariant– Something that must be true

• when not holding lock


Solving Too Much Milk Correctness properties

– Only one person buys milk• Safety: “nothing bad happens”

– Someone buys milk if you need to• Progress: “something good eventually happens”

First: use atomic loads & stores as building blocks– “Leave a note” (lock)– “Remove a note” (unlock)– “Don’t buy milk if there’s a note” (wait)


thread A

if (no milk && no note)

leave note

buy milk

remove note

thread B

if (no milk && no note)

leave note

buy milk

remove note

Does this work?too much milk

Too Much Milk: Solution 1


thread A

leave note A

if (no note B)

if (no milk)

buy milk

remove note A

thread B

leave note B

if (no note A)

if (no milk)

buy milk

remove note B

Idea: use labeled notes

oops – no milk



thread A

leave note Awhile (note B) do nothingif (no milk) buy milkremove note A

thread B

leave note B

if (no note A)

if (no milk)

buy milk

remove note B

Idea: wait for the right note

Quick Activity: does this work?



thread A

leave note A

while (note B)

do nothing

if (no milk)

buy milk

remove note A

thread B

leave note B

if (no note A)

if (no milk)

buy milk

remove note B

Possibility 1: A first, then B

OK



thread A

leave note A

while (note B)

do nothing

if (no milk)

buy milk

remove note A

thread B

leave note B

if (no note A)

if (no milk)

buy milk

remove note B

Possibility 2: B first, then A

OK



thread A

leave note A

while (note B)

do nothing

if (no milk)

buy milk

remove note A

thread B

leave note B

if (no note A)

if (no milk)

buy milk

remove note B

Possibility 3: Interleaved – A waits & buys

OK



thread A

leave note A

while (note B)

do nothing

if (no milk)

buy milk

remove note A

thread B

leave note B

if (no note A)

if (no milk)

buy milk

remove note B

Possibility 4: Interleaved – A waits, B buys

OK



Too Much Milk: Solution 3 Solution 3:

“Thread A waits for B, otherwise buys”

Correct – preserves desired properties– Safety: we only buy one milk– Progress: we always buy milk

But…


Problems with this Solution Complicated

– Difficult to convince ourselves that it works Asymmetrical

– Threads A & B are different– More threads=different code for each thread

Poor utilization– Busy waiting – consumes CPU, no useful work

Possibly non-portable– Relies on atomicity of loads & stores


Language Support Synchronization complicated Better way – provide language-level support

– Higher-level approach– Hide gory details in runtime system

Increasingly high-level approaches:– Locks, Atomic Operations– Semaphores – generalized locks– Monitors – tie shared data to synchronization


Locks Provide mutual exclusion to shared data

– two atomic routines• acquire – wait for lock, then take it• release – unlock, wake up waiters

Rules:– Acquire lock before accessing shared data– Release lock afterwards– Lock initially released

UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science

Locks and Queuing Acquire:

– if unlocked,go in;otherwise wait in line

Release:– Unlock &

leave

17


Pthreads Syntax POSIX standard for C/C++ Mutual exclusion locks

– Ensures only one thread in critical section

pthread_mutex_init (&l);…

pthread_mutex_lock (&l);update data; /* critical section */pthread_mutex_unlock (&l);


thread A thread B

Too Much Milk: Locks


thread A

p_m_lock(&l)

if (no milk)

buy milk

p_m_unlock(&l)

thread B

p_m_lock(&l)

if (no milk)

buy milk

p_m_unlock(&l)

Too Much Milk: Locks Clean, symmetric How do we implement it?


Implementing Locks Requires hardware support (in general) Can build on atomic operations:

– Load/Store– Disable interrupts

• Uniprocessors only– Test & Set, Compare & Swap


Disabling Interrupts Prevent scheduler from switching threads

in middle of critical sections– Ignores quantum expiration (timer interrupt)– No handling I/O operations

• (Don’t make I/O calls in critical section!)

Why not implement as system call?


Class Lock { private int value; private Queue q;

Lock () { value = 0; q = empty; }

public void acquire () { disable interrupts; if (value == BUSY) { add this thread to q;

enable interrupts; sleep(); } else { value = BUSY; } enable interrupts; }

public void release () { disable interrupts; if (q not empty) { thread t = q.pop(); put t on ready queue; } value = FREE;

enable interrupts; }

Disabling Interrupts


Locks via Disabling Interrupts


Summary Communication between threads

– via shared variables Critical sections

– regions of code that access shared variables Must be protected by synchronization

– primitives that ensure mutual exclusion– Loads & stores: tricky, error-prone– Solution: high-level primitives (e.g., locks)


The End


Pthreads API

Computer Systems Principles Synchronization

Documents