Introduction
Teaching team
Why concurrent programming?
In general
In this course
Gentle start
- Java
Teaching team
- Check the information tab
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.
Timing-related bugs
Require a particular timing of events to happen in the system in order to be triggered
May be difficult to reproduce
May be difficult to find during testing
Are significant part of bugs that found in production
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++) { counter++; } } 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 System.out.println(c.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
We expected the
counter++
operation to be executed at once (atomic)In fact it consists of two operations: read and write
The result of executing these operations by two processors concurrently is surprising
Synchronisation
Synchronisation is the restriction of the possible executions of a concurrent program in order to guarantee certain safety properties
Synchronization can be used to fix the problem with counter we have seen above
Why do we use concurrency?
- Pervasive in systems where events occur physically at the same time
Multi-core machines
Cell phones
Laptops
Even single-processor systems often contain logical concurrency
Software controllers which handle responses from several physical sources
Concurrency is also abstraction, used to simplify programs
Concurrency vs. Parallelism
Parallell programmering ≠ parallel programming
Parallel
- Physically at the same time
Concurrent
- Logically at the same time, but might be implemented without any real parallelism
The book covers parallel programming too – but we will briefly focus on it in the course
Course (general) goals
Introduction to the problems common to many computing disciplines:
- Operating systems
- Distributed systems
- Real-time systems
Appreciation of the problems of concurrent programming
- Classic synchronisation problems
Understanding of a range of programming language constructs for concurrent programming
Ability to apply these in practice to synchronisation problems in concurrent programming
Practical knowledge of the programming techniques of modern concurrent programming languages
Other goals
Advance your programming and problem solving skills
Consciously use a method for problem solving
Programming and problem solving skills are transferrable and applicable outside of the area of concurrent programming
Practical course information
About the course activities
Two (or three) lectures per week
Six to eight supervision/exercise hours
Assignments
- Four programming assignments – “labs” (two in Java and two in Erlang)
-
- 4 hours
- Closed book
-
Intended to answer most basic questions
Email tda383-dit390-concurrent-programming-period-3-2015-2016@googlegroups.com (group site)
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
- On a uniprocessor system threads appear to run at the same time but in fact their execution must be interleaved
The job of switching between threads is performed by the scheduler
Part of the run-time system, or
Performed using the operating system’s processes and scheduler
Many different methods of scheduling exist
Cooperative scheduling
- a thread runs until it is willing to release the processor (e.g. sleep or termination)
Preemptive scheduling
a thread is interrupted in order to let other threads continue (e.g. time-slicing)
Erlang have a preemptive scheduler
Most modern JVM’s are also preemptive
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
The models that we are going to use talk about what is possible, not about what is likely to happen
The reason for this is that we want to be prepared for worst case execution
Concurrency models, cont.
The models seen so far apply not only to Java, but most programming languages that use shared memory concurrency
Unfortunately, they are rarely stated explicitly in text books
Often information about them is buried very deeply in documentation or standards
Not understanding them will cause you to shoot yourself in the foot
This course: programming languages
We are going to
Explore concurrency problems and solutions
Understand how modern programming languages support concurrent programming
We will use two concrete programming languages
Java (shared memory concurrency)
Erlang (message passing concurrency)
What is ahead: part 1, shared memory concurrency
Analysing what are possible concurrent executions of a given program
Eliminaing bad executions: synchronization
Formulating correctness criteria that separate good executions from bad executions
Safety (nothing bad happens, program does not give wrong results)
Liveness (good things happen eventually, program terminates)
Debugging of concurrent programs
Based on Java (also pseudo languages)
What is ahead: part 2, other concurrency models
Message passing concurrency
Software Transactional Memory
Erlang
Comments from the last instance
What did you lack? I had no experience with functional programming, but the coverage in the course was alright for catching up to the course.
The course workload as related to the number of credits was... the erlang labs took too much time. especially considering that it's a functional programming whcich we hadn't encountered before, at all.
What is your overall impression of the course? Learning Erlang was very fun.
How have group roles and cooperation between students worked? Good.
What is most important to change for the next round of this course? For lots of people break it or make it depends on whether the course sowtware can be installed on their homecomputers,
Summary
Today’s lecture
Introduction to concurrency
Threads in Java
The shared update problem (counter)
Next time
Solving the shared update problem
Introduction to the first programming lab
language construct for synchronisation (semaphores)