Welcome!
TDDC47
• ... To this special course for Y students!
Real-time and Concurrent
Programming
• Consists of two parts as the name
indicates:
Lecture 1: Course overview &
Introduction to processes
– Concurrent processes
(sv. processprogrammering)
– Real-time systems
(sv. realtidsprogrammering
Simin Nadjm-Tehrani
Real-time Systems Laboratory
Department of Computer and Information Science
Linköping University
Undergraduate course TDDC47
Linköping
46 pages
Autumn 2010
Course overview
• Concurrent processes
• Normally part of two courses (6hp+6hp)
• Here we do 3hp+3hp of each!
Undergraduate course TDDC47
Linköping
2 of 46
Autumn 2010
What is this course about?
• Course content in each part:
– Synchronization and mutual exclusion
– Resource sharing and deadlock
– Process
– Concurrency
– Resource sharing basics
• Real-time systems
– Scheduling for hard real-time systems
– Real-time communication with hard
deadlines
– Dependability and treatment of faults
Typically part
of an OS
course
– Real-time processes & scheduling
– Time-constrained communication
– Timing and other faults
• Web page: www.ida.liu.se/~TDDC47
Typically part of a RT course
Undergraduate course TDDC47
Linköping
3 of 46
Autumn 2010
Undergraduate course TDDC47
Linköping
Course literature
• No “one book” covers the material
commissioned for the course
• There are four resources for study
– Compendium (Nordström et.al.)
– Burns & Wellings
– Silberschatz et.al.
– 3 articles
• Detailed guidelines for reading on the
course web!
Undergraduate course TDDC47
Linköping
4 of 46
Autumn 2010
Updated information
• www.ida.liu.se/~TDDC47
– Give constructive feedback if you miss
something!
• Look out for potential changes in
schedule and messages!
• Your other contacts:
– Course assistant: Mikael Asplund
– Lab/lesson assistant: Jordi Cucurull
– Course secretary: Madeleine Häger
(anything about exam results/Ladok)
5 of 46
Autumn 2010
Undergraduate course TDDC47
Linköping
6 of 46
Autumn 2010
1
Examination
Lab organisation
• Laboratory exercises (1.5 hp)
– Examined by lab assistant
• Follow the instructions on the web for
registration and forming the lab groups
• Theory:
y written examination (4.5
(
hp)
p)
• Read the lab material, attend the
l
lesson,
and
d prepare before
b f
th labs
the
l b
• Estimated work needed: 40 hours
• Scheduled hours in lab (with
assistance): 16h including 4h for
demonstration
– Performed in pairs
– Not only calculation type questions!
– Help to understand concepts:
• reading literature, formulating own
questions and attending lessons
• I give feedback on attempts to answer
(earlier exam) questions!
Undergraduate course TDDC47
Linköping
7 of 46
Autumn 2010
Undergraduate course TDDC47
Linköping
8 of 46
Autumn 2010
Finishing on time
• Lab assistance in 2011 will have to be
individually organised (subject to
assistant availability)
Contact/Queries
• Use your feedback opportunity:
– Muddy cards
• To answer questions:
• Please observe the instructions for
– Finishing the labs before deadline
– Re-examination sessions will be announced
for April/August
Undergraduate course TDDC47
Linköping
9 of 46
Autumn 2010
– Simin/Mikael/Jordi on theory of processes
and real-time topics
• Outside scheduled hours available by
appointment through mail
Undergraduate course TDDC47
Linköping
Web evaluations 2009
• Indicated issues with the lab exercises,
level of assistance obtained, and
connections between lectures, labs, and
lessons
2010: We have
completely
changed the labs
and added one
more assistant!
Undergraduate course TDDC47
Linköping
11 of 46
Autumn 2010
10 of 46
Autumn 2010
This year’s set up
• We have a tight relation between the
labs and the concurrent processes
theory
– You do part of the classic OS course
Pi t llabs!
Pintos
b !
• We have taken away the control
performance and feedback scheduling
parts to make the course structure
clearer, and provide better focus
• Led by best two assistants at IDA!
Undergraduate course TDDC47
Linköping
12 of 46
Autumn 2010
2
Web evaluations 2009
From evaluations 2008
• Muddy cards:
• Hard to study for a course with two out
of three books which only partially cover
Contact me!
• A number of earlier editions of course
books (still relevant) available for loan
from course team
• See also links to electronic books
Undergraduate course TDDC47
Linköping
13 of 46
Autumn 2010
– Spreading the course over two periods was
not desirable
• This year the course is run over one
period (at LiTH such changes have a
latency of ~one year...)
Undergraduate course TDDC47
Linköping
14 of 46
Autumn 2010
Web evaluations 2008
• Hard to study for exam
– A new element: Test on process part of the
course based on earlier exam questions
was introduced in 2009
• All students who handed in their
solutions in 2009 got detailed
comments!
• Several sent mails and got detailed
comments
Undergraduate course TDDC47
Linköping
Questions?
15 of 46
Autumn 2010
This lecture
Undergraduate course TDDC47
Linköping
16 of 46
Autumn 2010
Forthcoming lecture topics
• The notion of Process and related concepts
(3,5 lectures)
– Resource sharing & Synchronisation
– Deadlocks, livelocks, and starvation
• Real-time Resource allocation: scheduling (2,5)
• Real-time communication networks (1)
• Fault management and dependability(1)
In English
• Guest lecture from industry
• Concurrency and execution
• Processes, threads, and their
representation
• Communication
• Synchronisation
• RE: Summary and on-demand question session
Undergraduate course TDDC47
Linköping
17 of 46
Autumn 2010
Undergraduate course TDDC47
Linköping
18 of 46
Autumn 2010
3
The notion of Process
• An abstraction in computer science used
for describing program execution and
potential parallelism
• What other abstractions do you know?
– Functions
– Classes, Objects, Methods
• “Tasks” is another term used for
computational processes
Undergraduate course TDDC47
Linköping
19 of 46
Autumn 2010
What is a process?
Abstraction for modelling:
• A program in execution
This course!
• Parallel developments
p
in a p
physical
y
environment
• Computations in network nodes that
interact with each other
Undergraduate course TDDC47
Linköping
20 of 46
Autumn 2010
Why process as abstraction?
Concurrent Programs
• Other programming abstractions focus
on a static description of programs as
– Functions
– Modules
– Methods
A sequential program has a
single thread of control.
A concurrent program has
multiple threads of control
allowing it perform multiple
computations in parallel and
to control multiple external
activities which occur at the
same time.
• Processes emphasise the run-time
behaviour
[Magee and Kramer 2006]
Undergraduate course TDDC47
Linköping
21 of 46
Autumn 2010
Undergraduate course TDDC47
Linköping
Concurrency
• A mathematical term for modelling
computational processes that could in
principle be run in parallel
Pseudopa allel
parallel
• Three possibilities:
– Single processor, shared memory
– Multi-processor, shared memory
– Multiple processors not sharing
memory
Undergraduate course TDDC47
Linköping
23 of 46
Autumn 2010
22 of 46
Autumn 2010
Related terms
Concurrent programs
Define actions that may be
performed simultaneously
Parallel programs
A concurrent program that is
designed for execution on parallel
hardware
Distributed programs
Parallel programs designed to run
on network of autonomous
processors that do not share
memory
Undergraduate course TDDC47
Linköping
24 of 46
Autumn 2010
4
Run-time behaviour
Concurrent on single CPU?
Running processes on a single CPU:
• More efficient use of the processor
C
• Increased responsiveness, e.g. user
interaction can be given priority
B
A
Time
Undergraduate course TDDC47
Linköping
25 of 46
Autumn 2010
Undergraduate course TDDC47
Linköping
26 of 46
Autumn 2010
Historical data…
Response tim
me in seconds
• To fully utilise the processor
10
2
1
10
0
10
-1
10
-2
10
-3
10
-4
10
-5
10
-6
10
-7
10
10
10
[Wellings04]
human
tape
floppy
CD
memory
-8
-9
Summary
• A concurrent program consists of a set
of autonomous computation processes
(logically) running in parallel
• A process has its own thread of control
and its own address space
• Operating system may arbitrarily switch
among processes and give control of the
CPU to some process
processor
Undergraduate course TDDC47
Linköping
27 of 46
Autumn 2010
Undergraduate course TDDC47
Linköping
28 of 46
Autumn 2010
Each process
• Is managed by the OS and has
– A process ID
– A record of its run-time data kept in the OS
“process control block” - PCB
• Is allocated segments in the memory:
– Code: the machine instructions it will run
– Data: global variables and memory allocated
at run-time
– Stack: local variables and records of
functions activated
Undergraduate course TDDC47
Linköping
29 of 46
Autumn 2010
Process life cycle
Non-existing
Created
Terminated
Initialising
Ready
Ready
Waiting
Executing
Executing
Undergraduate course TDDC47
Linköping
30 of 46
Autumn 2010
5
Analogies
• Cooking recipe: program
• Preparing a dish: running different
instances of concurrent processes
• Looking for ingredients: initialisation
Undergraduate course TDDC47
Linköping
Programming for processes
• Typical real-time systems: Assembler, C
– Need support from OS to create,
schedule and terminate tasks
• Languages with support for concurrent
programming: Java, Ada
– Have their own run-time system and
can explicitly create processes
Undergraduate course TDDC47
Linköping
31 of 46
Autumn 2010
Program/process structure
• Static/Dynamic
• Nested/Flat
Not part of
this course
• Substantial differences between various
languages wrt syntax, execution model,
and termination semantics for nested
processes
Undergraduate course TDDC47
Linköping
Threads (& tasks)
• Some modern operating systems allow a
process to create (spawn) a number of
parallel threads of control – in the same
address space
• Each process has its own stack
• Processes that run with a shared
address space (code, data) are called
light-weight processes or threads
• In this course we consider processes
with one thread of control and use tasks
interchangeably with processes
Undergraduate course TDDC47
Linköping
33 of 46
Autumn 2010
Logical parallelism
P1:
P2:
{while true do
think;
talk
}
{while true do
sleep;
listen
}
32 of 46
Autumn 2010
34 of 46
Autumn 2010
Context Switch
• Consider a program that consists of
processes P1,…, P4
• An execution of the concurrent program
may look like:
P2
P1
P4
Which potential execution sequences (traces)?
P3
Context switch
time
Undergraduate course TDDC47
Linköping
35 of 46
Autumn 2010
Undergraduate course TDDC47
Linköping
36 of 46
Autumn 2010
6
Keeping track of execution
• Each process in PCB has:
– Process state (which stage in life
cycle)
– Program counter (where in its running
code)
– Value of internal variables
– The allocated memory areas
– Open files and other resources
Undergraduate course TDDC47
Linköping
37 of 46
Autumn 2010
This lecture
• Concurrency and execution
• Processes, threads, and their
representation
• Communication
• Synchronisation
Undergraduate course TDDC47
Linköping
Process communication
Data sharing:
• Output for one process may be input for
another process
38 of 46
Autumn 2010
Communication
• Two modes:
– Shared variables
– Message passing
– Compute distance, and then compute incremental
acceleration
Flow of control (synchronisation):
• One process may only start after another one
finished
– Update display only after all sensor values are
received
Process A
Process B
Process A
Shared
Process B
• Sharing common resources
Processes
must
– No more than one process at a time may send
a
notify each
packet on a shared channel
other
Undergraduate course TDDC47
Linköping
39 of 46
Autumn 2010
Kernel
Kernel
Undergraduate course TDDC47
Linköping
Basic operation
Problems?
• No! Since hardware memory can
support atomic memory update, so that
only one writes at a time
• But…
• Creates problems for more complex
shared data structures
• Communication using shared variables
P2
P1
40 of 46
Autumn 2010
– Update date, time and stock value
Writes to X
Reads from X
– Register a call to a telecom server before serving it
– Is the call on the register the earliest unserved one?
Even if server is overloaded?
Variable X
Undergraduate course TDDC47
Linköping
• One process may write at a faster rate
than the other process reads
41 of 46
Autumn 2010
Undergraduate course TDDC47
Linköping
42 of 46
Autumn 2010
7
Race condition
• Consider two processes P1 and P2 that are
allowed to write to a shared data structure
Decoupling from process rates
• Finite buffers
• If the order of updating the data structure by
respective processes can affect the outcome of
the computation then the system suffers from
a race condition
P1
P2
– Analogy: Deposit 5000kr in the account, calculate
accrued interest
• Process synchronisation is used to avoid race
conditions
Undergraduate course TDDC47
Linköping
43 of 46
Autumn 2010
Writes to buffer
Reads from buffer
Finite buffer
Undergraduate course TDDC47
Linköping
Issues
44 of 46
Autumn 2010
Message from LiU
• Must check that buffer is not full when
writing to it
• Must check that buffer is not empty
when reading from it
• Must ensure that two processes do not
write on one buffer position at the same
time
synchronisation and
shared data problems
Undergraduate course TDDC47
Linköping
45 of 46
Autumn 2010
Undergraduate course TDDC47
Linköping
46 of 46
Autumn 2010
8