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 sleep
  • wake(t) wakes up thread t
  • 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)

---