Summary
- The course is a general introduction to concurrent programming, and its foundamental concepts
- Synchronisation problems
- Concurrent computation models
- Problems that may arise in concurrent systems: corruption, deadlock, starvation
Synchronisation problems
Mutual exclution (mutex)
Readers-writers
Dining philosophers (deadlock)
Readers-writers (starvation)
Shared memory models
Shared memory (SM) with atomic reads and writes
- Model close to real shared memory machine models
- The model initially used to solve classical synchronisation problems (mutual exclusion)
- Prominent algorithm for mutual exclusion: Peterson's algorithm
- Requires busy-waiting
- Real hardware is more complicated
- Solving a synchronisation problem—inventing a protocol
SM with additional atomic instruction
- Compare-and-swap (CAS)
- Test-and-set
- Linked-load/conditional-store (LL/CS)
- This kind of instructions are used by real systems
- Implementing synchronisation primitives is much easier (and more efficient)
SM with instructions for putting a thread to sleep and waking it up
sleep()
puts the current thread to sleepwake(t)
wakes up threadt
current()
returns the current thread id- Instead of busy-waiting, the waiting thread can be put to sleep, and woken up later by another thread
- Typically there are more threads than processors
- Threads are governed by a scheduler
SM with semaphores
SM with monitors
- The Java model
- SM + atomic instructions + semaphors + monitors + ...
- You cannot rely on unsynchronised reads and writes
Other models
Message passing
- We've looked at Erlang model
Erlang model
- Isolated processes (separate heaps)
- Asynchronous message send
- Selective receive
Software Transactional Memory (SM)
- Atomic blocks
- Implemented using atomic instructions
Linda
- Isolated processes communicating using blackboard
Server-client
- Using shared a resource by many clients using message passing
- Very similar to a monitor
Workers
- Independent tasks
- Typically only some of them are running at the same time
- Typically no preemption
- Can be 'gentle' for the resources (and more efficient)
Problems
Corruption (safety)
- Forgetting to hold a lock
- Race conditions
Sequential bottle-necks
- Holding too many locks
- Contention points
- Inherent bottle-necks
- Threads competing for bandwidth
Deadlocks
- Also unnecessary delays
Starvation
- | SM + sem or mon | STM | Message passing |
---|---|---|---|
Corruption | -- | no | - |
Deadlocks | -- | no | - |
Starvation | - | -- | - |
Correctness
Establishing correctness of concurrent program can be very difficult
- Subtle errors can undermine it
- Failures might be very rare and difficult to debug
Properties
- Safety properties (mutual exclusion, etc.)
- Liveness properties (deadlock freedom, starvation freedom)
- The exact property is specific to the problem
- Typical high-level safety property: sequential consistency
State transition diagrams
- Work when there is a finite and small number of states
Invariants
- Formulas which are true for all reachable states
- Invariants are used to rule out some states
- When some states are ruled out, proving your property might be much easier
There is a rich set of tools used to prove properties of concurrent programs
- Not discussed in this course
- Operating on state spaces
- Go to Software Engineering using Formal Methods (TDA293/DIT270, LP1) if you want to know more!
Sequential consistency
Very useful high-level correctness property
Says that operations behave in a consistent way as if they were performed by a single thread
You can use a sequential specification
Typical property of databases
- Also called serializability
- Check out Databases (TDA357/DIT620, LP2 and LP3)
Debugging concurrent programs
Often all you have is a trace
- You need to reason backwards to find out what went wrong
When things get complicated
- Keep track of your observations (evidence)
- Keep track of your hypotheses (and eliminate them)
Realtime properties
- In this course we don't care about real time properties of our programs
- We are happy as long as things happen 'eventually'
- Real-Time Systems (EDA222/DIT161, LP3)
- Parallel and Distributed Real-Time Systems — follow-up on EDA222 (EDA421/DIT171, LP4)
Parallel programming, efficiency
Important factors
- How parallelizable your workload is
- Contention
- Memory bandwidth
- Size of tasks
Sometimes problems that seem to be sequential can be parallelized
Parallel Functional Programming (DAT280/DIT261, LP4)
The message
You have learned classical synchronisation problems and how to solve them
You should have an overview of different ways of programming concurrent systems
You should what can go wrong and how to fix it
With all that, you should want to avoid dealing with concurrency yourself (and let others do the dirty work)
- Use high-level constructions
- When you use the right model then your code will hopefully be 'simply correct' (for example: replacing a complex semaphore kludge with STM)