Concurrent & Distributed Systems: Introduction

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

2. 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

3. 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

4. What are concurrent processes:1 ? • According to the dictionary, processes “taking place at the same time”. • This does notnecessarilymean 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

5. 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 • 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

6. 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 externalevents, eg in Embedded Systems (more of this later) Concurrent & Distributed Systems

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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