Transcript Lecture 1

Concurrent & Distributed Systems: Introduction
•
•
•
•
What do we mean by Concurrent Systems?
Why do we study them?
Some more technical details.
A good start at the practicalities of running concurrent programs
Concurrent & Distributed Systems
1
What is a Concurrent Program ?
•
•
•
Concurrent, in the dictionary means ‘taking place at the same time’.
A program is what you write (with a text editor) in a computer language (Java,
Pascal etc), to be compiled eventually into machine code instructions to execute
on a CPU.
– Programs are static – think of them as text on paper or in files
– Programs executing on a CPU are dynamic and are called:
• Processes (often in Operating Systems textbooks)
• Tasks (often in Real Time [WWCH?] Programming)
• Threads (in Java, for example). Also called ‘lightweight processes’
– There are differences between these terms – see extra notes
about Processes, Tasks and Threads.
– We will use the word ‘process’ for a program in execution.
– Every process has to have an algorithm, coded up in a
programming language.
Only actions can be concurrent, so we really want to think about concurrent
processes/tasks/threads. Also called ‘multi-threading’. So concurrent programs
are written to supply the program code for multiple processes /tasks /threads to
run concurrently. Exactly How you write such programs varies from
environment to environment (Java, InTime, ADA, Linux etc)
Concurrent & Distributed Systems
2
What are Single Threaded programs ?
•
•
•
The normal programs you first learnt when you started programming (in Java,
C++ or whatever). E.g. to write ‘Hello’ on the screen, or to calculate a resonant
frequency from inputted circuit data.
– ‘Single threaded’ is a modern, very good phrase to use.
Single threaded programs have important properties:
– If you run them many times, with the same input data, the machine code
instructions will be executed in exactly the same order, with exactly the
same results. Only the time taken might be different, if you are using
different CPUs (c.f. Real Time Systems).
– As a consequence, testing single threaded programs is reasonably
straightforward – you run the program many times with different input data
(chosen by referring to the program’s specification) and check whether or
not the results are what the specification says. For any one set of data
inputs there will be only one thread of execution (the detailed sequence in
which the CPU goes through the code – this we will call a scenario).
– There is only one algorithm to worry about.
– They have single start and finish points.
Think about this – are most programs single threaded?
Concurrent & Distributed Systems
3
What are concurrent processes:1 ?
•
According to the dictionary, processes “taking place at the same time”.
– This does not necessarily mean executing on a CPU at the same time! (This
is a good example of where everyday language can lead us astray). It can only be true with
>1 CPU, in which case we have true parallel processing.
– So multiple processes can be concurrently executing on the same CPU. In
this very common case, “taking place” means “started and in progress,
but yet completed”. The CPU will then have to switch between processes
to execute them (this is Context Switching – see extra notes Processes,
Tasks, Threads).
– Context Switching is controlled by part of the Operating System called the
scheduler. There are many possible scheduling schemes – ‘Round Robin’
is the simplest to think about.
– Concurrent processes can be called ‘pseudo-parallel’ or ‘potentially parallel’
processes, since each one could be given its own CPU if we had the
money.
– Are there any differences between:
• 10 processes running concurrently on a single 1GHz CPU context
switching between them in round robin fashion.
• 10 processes running concurrently each on its own 100MHz cpu?
Concurrent & Distributed Systems
4
Concurrent processes (context switching: 1)
•
•
Note that here there is just one CPU, switching between the four processes.
The scheduler here is Round Robin, giving equal time slots to each process
Four Concurrent processes on a single CPU
P1
P2
P3
P4
Degree
1
2
3
3
3
3
2
2
2
2
2
1
running on CPU
saving context of previously running process
process starts
loading context of next process to run
1
process ends
•
•
In principle, the scheduler doesn’t always need to both save and load contexts –
it depends on the degree of concurrency
Context switching time is greatly exaggerated in the diagram above
Concurrent & Distributed Systems
5
Concurrent processes (context switching: 2)
•
There are lots of ways for schedulers to implement context switching
– On your own PC, for example
• On demand from a user – every time you minimise or maximise
something on your Windows PC with a mouse click, you are effectively
switching a process out of or into the CPU. This is an example of
‘event driven’ context switching.
• At given times – your virus checker or backup program might be
switched in at pre-determined times.
• Have a look at how many processes there are on your PC (press
control-alt-delete to get the Windows Task manager and select the
‘processes’ tab – then you can see all the processes currently in
memory and what % of CPU time they are getting from the scheduler).
– On the basis of priorities allocated to the processes or users (still used on
mainframe computers, which are still around!)
– To service external events, eg in Embedded Systems (more of this later)
Concurrent & Distributed Systems
6
Concurrent processes: Interactions
•
•
•
•
•
•
Independent processes could be:
– 1. Un-related programs running on quite different computers.
– 2. Un-related programs sharing the same CPU on one computer (eg Word
and, say, a Pascal program of your own)
Such processes might be concurrent in the crude sense of actually being in
progress at the same time, but
If the processes don’t interact then they are not of any interest to us as
concurrent processes.
So concurrent processes are always systems (things made of identifiable bits
which interact to do something which is more than just the aggregate of what
each bit does – systems have system properties). Hence the title of this Unit.
Clearly we are going to have to look very carefully about how the different
processes in a concurrent system can interact – almost all of this unit is about
this!
PS You could argue the processes in example 2 above do interact, at a deeper
level – think about this.
Concurrent & Distributed Systems
7
Concurrent processing: Why ?
•
•
Reason 1: It was historically necessary for early computer users
– Individual PC’s did not exist before 1976 (first appeared in Byte magazine).
Before then, computing was done by very expensive ‘mainframe’ computers
(most big organisations, including South Bank still use mainframes, eg to
run LSBU’s Blackboard, exchange services etc).
– So to provide a computer service to many users at their own desks, each
user had a ‘dumb’ terminal (just a keyboard and screen, without a CPU or
local memory, linked as a terminal to the mainframe.
– Since the mainframe would have had one CPU, it needed a multitasking
operating system with a scheduler to context switch between all the users.
This is called ‘timesharing’. Most of the fundamental research about how to
handle concurrent processes was done in figuring out good designs for
these multi-tasking operating systems (the most famous being Unix).
– This still happens – you can still log in to the LSBU mainframe, using a PC
essentially as a dumb terminal.
Reason 2: Modern PC’s need to multi-task
– The original PCs ran MsDOS, only able to run one process at a time
– Modern Windows based PCs need to be able to multi-task.
Concurrent & Distributed Systems
8
Concurrent processing: Why ? (continued:1)
•
Reason 3. Even the biggest, fastest CPU is not big enough for ‘really big’
computational problems (e.g. simulating tsunami waves). So really big
computers have to use many CPUs in true parallel arrangements, just to get the
power. Hence the big algorithms have to be designed as many separate but
interacting processes, each to run on one CPU. So really big computers are
examples of concurrent systems. They might also be Distributed Systems if
they interact by passing messages over a link like the Internet ( the biggest
computers in the world are like this).
– Note: designing parallel algorithms is a very difficult and specialised
business – so apart from one simple sorting example, we won’t go further
with this.
– Some problems/techniques do fit well with parallel computation, e.g.
• Finite element methods
• Vector and matrix calculations
•
All these first three reasons are to do with providing computing power to users
who want to do some computation (using a program to transform data from
one form into a more useful form – besides calculating numbers, this includes
things like word and image processors and programs to change the key of a
piece of music….)
Concurrent & Distributed Systems
9
Concurrent processing: Why ? (continued:2)
•
Reason 4. This is much more important than the first three. Most actual CPUs
sold end up as parts of Embedded Systems. These are defined (WWCH) as
systems which contain CPUs and memory, but whose purpose is not
computation.
– So many modern things are computer controlled that there are thousands
of examples, from small to very large:
• Xmas cards
• Chip and Pin cards
• Washing machines and all kinds of ‘white goods’
• Cars
• Airplanes
• Factories
• Health Systems
• Military Systems
• Communication Systems
• etc
Concurrent & Distributed Systems
10
Concurrent processing: Why ? (continued:3)
•
Reason 4. Embedded Systems
– The main inputs and outputs to the computers in embedded systems are
not keyboards and screens (most embedded systems don’t even have
these) – they are sensors and activators.
– There will be many sensors providing data and many activators controlling
the systems activities
• A washing machine might sense water temperatures, water pressure,
water level, weight of the clothes, speed of the drum. It might activate
a water heater, several pumps, several motors, indicators, door lock.
• More than one process is needed to handle all this and the processes
will certainly interact (e.g. the process controlling the spinning and the
process controlling the pumping). So our washing machine is an
embedded concurrent system.
• Sensors connect an embedded system to events in the real world,
where things happen according to the laws of physics. So the events
will usually be concurrent and the system’s processes will be
asynchronous or not depending on what is happening in the real world.
More about synchronisation later.
Concurrent & Distributed Systems
11
What? Why? Context? How? (WWCH)
•
Always check your understanding of anything (X) by asking yourself the 4
WWCH questions. Good engineering.
•
What? First define carefully what X really is. You’d be surprised how many
people brag on about something when they really don’t even know what it is “my car’s got real time ABS brakes”. If you can’t answer the what question, you
can’t even start to understand X. You can start with a dictionary, if nothing else.
Be careful about terminology – people use different words for the same thing –
even engineers. Use ‘Data Dictionaries’ to make things clear.
•
Why? Is thing X interesting, relevant or important. You need to know this,
otherwise you might be wasting your time on it. It may not be immediately
obvious, so some research and/or questioning others may be needed. You
should be able to answer the why question about anything you do!
•
Context? You should be able to figure out how X fits in with the rest of the world.
This will often include social, political and commercial aspects of X. In fact these
dimensions might be more important than any purely technical aspects of X.
This is closely related to the why? question, of course.
Concurrent & Distributed Systems
12
WWCH Continued
•
How? Does X work, technically. This is the detail. Depending on the
circumstances, you might need lots of detail here, or a little, or none! Science
and maths knowledge is needed to answer the How question. You do a lot of
work in all your classes to get the How question sorted out – but remember that
it is only one of the four questions.
•
The first of the four WWCH questions is essential, the second pretty much
essential, the last two depend on how deep your understanding of x needs to
be.
•
Finally, remember that even when you have sorted out out all the WWCH
answers, you won’t be much use (to an employer or customer) if you can’t
communicate them clearly. So you have a whole lot of skills in good engineering
communication to acquire as well.
Concurrent & Distributed Systems
13