Teaching team

Why concurrency?

Lock screen bug in iOS 9

From iDownloadBlog:

If you have an iPhone running iOS 9, you should be aware that it may be possible to access your photos and contacts on a locked device, even with a passcode and/or Touch ID enabled.


Step 2: Enter 3 digits towards an incorrect fifth passcode, and press and hold the Home button to invoke Siri followed immediately by the 4th digit.


Step 15: You will now see all of the photos and albums on the device, which is still locked. You can now browse and view each photo individually.

What is the most likely explanation for this bug?

Other lock screen bugs

IOS has a long history of lock screen bugs, part of which can be found here.

Version 7.0.2 had this bug, for example. The bug has been fixed in iOS 7.0.3, and received the following description:

Race conditions existed in the Phone app at the lock screen. Under various circumstances, the Phone app may allow access to the Contacts pane. This issue was addressed by preventing this display of the Contacts pane while the phone is locked.

A Java example

class Counter implements Runnable {

  private int counter = 0;
  private final int rounds = 100000;

  public void run () {
      for(int i = 0; i < rounds; i++) {

  public static void main (String[] args) {
    try {
      Counter c = new Counter ();

      // Create two threads that run our run () method.
      Thread t1 = new Thread (c, "thread1");
      Thread t2 = new Thread (c, "thread2");

      t1.start (); t2.start ();

      // Wait for the threads to finish.
      t1.join (); t2.join ();

      // Print the counter
    } catch (InterruptedException e) {
      System.out.println ("Interrupted!");

Run the example and explain the results.

A model of execution

In order to explain the results we need to use a (mathematical) model of execution. We will use a simplified model where a number of CPUs are connected to shared consistent memory.

What happens in reality is much more complicated, but this simplified model will be enough to explain most of the behaviours discussed in this course.

Sequence of memory operations

This is one possible sequence of memory operations.

thread1 thread2

counter = 0

    0 <- read(#counter)
    write(#counter, 1)

counter = 1

    1 <- read(#counter)
    write(#counter, 2)

counter = 2

    2 <- read(#counter)
    write(#counter, 3)

counter = 3

    3 <- read(#counter)
    write(#counter, 4)

counter = 4

However, other orders are also possible.
thread1 thread2

counter = 0

    0 <- read(#counter)
    0 <- read(#counter)

counter = 0

    write(#counter, 1)

counter = 1

    write(#counter, 1)

counter = 1


Why do we use concurrency?

Concurrency vs. Parallelism

Parallell programmering ≠ parallel programming

Course (general) goals

Other goals

Practical course information

Another model of execution

In fact, Java allows us to run more threads than we have CPUs. At any given time there is at most one thread running on a CPU.

Threads scheduling

Simplified model with threads

Since we do not control the allocation of threads to CPUs, we may assume that any thread may be executing at any given time, and remove CPUs from the equation.

Concurrency models

Concurrency models, cont.

This course: programming languages

What is ahead: part 1, shared memory concurrency

What is ahead: part 2, other concurrency models

Comments from the last instance


Concurrent Programming 2016 - Chalmers University of Technology & Gothenburg University