CSE 425: Concurrency II

Semaphores and Mutexes• Can avoid bad inter-leavings by acquiring locks

– Guard access to a shared resource to take turns using it

• Dijkstra’s semaphore mechanism is one exampleSem s(n); Delay(s); [critical region of code] Signal(s);

– Where semaphore S gives up to n threads access at a time– Implement via a test-and-set instruction, spin-locks, etc.

• A binary semaphore (a.k.a. a mutex) if n == 1 – Encodes basic common semantics for mutual exclusion– Can allow optimized implementation (e.g., Linux futexes

avoid system calls unless there is contention for the lock)

• Can implement either one using the other– Update a counter within mutex-guarded method– Initialize a semaphore with a count of 1

CSE 425: Concurrency II

Deadlocks and other Issues• Synchronization may cause deadlocks

– Cyclic dependence, mutual exclusion lead to deadlock– Even if a deadlock has not occurred yet, code may reach a

path on which deadlock becomes unavoidable

• Protocols/mechanisms to avoid/detect/break deadlock– E.g., via Dijkstra’s Banker’s algorithm, timed locking, etc.

• Fairness/liveness of lock access scheduling matters– Order in which threads are given access to a lock may vary

• Accidental complexity also matters– E.g., user’s ability to mis-configure locking and concurrency – Motivates alternate uses of mutexes and/or semaphores– Encapsulating locks within type-safe object model may help

CSE 425: Concurrency II

Nonblocking (Lock-Free or Wait-Free)• Lock-free behavior never blocks (but may live-lock)

– Suspension of one thread doesn’t impede others’ progress– Tries to do something, and if it cannot just tries again– E.g., while(head.compare_exchange_weak(n->next,n));

• Wait-free behavior never starves a thread– Progress of each is guaranteed (bounded number of retries)

• Lock-free data structures try for maximum concurrency– E.g., ensuring some thread makes progress at every step– May not be strictly wait-free but that’s something to aim for

• Watch out for performance costs in practice– E.g., atomic operations are slower, may not be worth it– Some platforms may not relax memory consistency well

CSE 425: Concurrency II

C++11 Atomic Types

• Many atomic types in C++11, some are lock-free– Always lock-free: std::atomic_flag– If it matters, must test others with is_lock_free()

• Also can specialize std::atomic<> class template– This is already done for many standard non-atomic type– Can also do this for your own types that implement a trivial

copy-assignment operator, are bitwise equality comparable

• Watch out for semantic details– E.g., bitwise evaluation of float, double, etc. representations– Equivalence may differ under atomic operations

CSE 425: Concurrency II

Today’s Studio Exercises

• We’ll code up ideas from Scott Chapter 12.3 – Using threads, mutexes, and other C++11 types– Looking at synchronization, deadlock, and concurrency

• Today’s exercises are again in C++– Please take advantage of the on-line tutorial and reference

manual pages that are linked on the course web site– The Makefile provided last time also may be helpful– As always, please ask us for help as needed

• When done, send an email with your answers to the cse425@seas.wustl.edu course account, with subject line “Concurrency Studio II”