Concurrent Programming

1. ConcurrentProgramming K. V. S. Prasad Dept of Computer Science Chalmers University September– October2012

2. Website • http://www.cse.chalmers.se/edu/year/2012/course/TDA382_Concurrent_Programming_2012-2013_LP1/ • Should be reachable from student portal • Search on ”concurrent” • Go to theircourse plan • From there to ourhome page

3. Teaching Team • K. V. S. Prasad • Michal Palka • Ann Lillieström • Staffan Björnesjö

4. Contact • Join the Google group • https://groups.google.com/forum/?fromgroups#!forum/tda381-concurrent-programming-period-1-2012 • From you to us: mail Google group • Or via your course rep (nextslide) • From us to you • Via Google group ifone person or small group • News section of Course web page otherwise

5. Course representatives • Needoneeach for • CTH • GU • Masters (students from abroad) • Chooseduring first break • Reps thenmail Google group • Meet at end of weeks 2, 4 and 6 • Exact dates to be announced • Contact your reps for anonymous feedback

6. Practicalities • An average of twolectures per week: for schedule, see • http://www.cse.chalmers.se/edu/year/2012/course/TDA382_Concurrent_Programming_2012-2013_LP1/info/timetable/ • Pass = >40 points, Grade 4 = >60p, Grade 5 = >80p out of 100 • WrittenExam 68 points (4 hours, closedbook) • Fourprogrammingassignments – labs – 32 points • To be done in pairs • Must pass all four to pass course • Seeschedule for submission deadlines • (8 points on first deadline, 6 on second, 4 on third) • Supervision available at announcedtimes • Optionalexerciseclasses

7. Textbook • M. Ben-Ari, ”Principles of Concurrent and DistributedProgramming”, 2nd ed Addison-Wesley 2006

8. Otherresources • Last year’sslides • Ben-Ari’sslides with reference to the text • Language resources – Java, JR, Erlang • Gregory R. Andrews • Foundations of Multithreaded, Parallel, and DistributedProgramming • Recommendedreading • Joe Armstrong • Programming in Erlang • Recommendedreading

9. Course material • Sharedmemoryfrom 1965 – 1975 (semaphores, criticalsections, monitors) • Ada got these right 1980 and 1995 • And Java gotthesewrong in the 1990’s! • Messagepassing from 1978 – 1995 • Erlang is from the 1990’s • Blackboardstyle (Linda) 1980’s • Good, stable stuff. What’snew? • Machine-aidedproofssince the 1980’s • Havebecomeeasy-to-dosince 2000 or so

10. Course still in transition! • Good text book • but still no machine-aidedproofs in course • WenowuseJave, JR and Erlang • Only as implementationlanguages in the labs • For discussion • pseudo-code as in book • Gradedlabs new • so bear with usifthere are hiccups

11. To get started: • What is computation? • States and transitions • Moore/Mealy/Turingmachines • Discretestates, transitionsdepend on currentstate and input • What is ”ordinary” computation? • Sequential. Why? Historicalaccident?

12. Example: the Frogs • Slides 39 – 42 of Ben-Ari • Pages 37 – 39 in book

13. Examples (make your ownnotes) • Naturalexamplesweuse (whydon’twe program like this?) • Largestof multiset by handshake • Largest of multiset by broadcast • Sortingchildren by height • Occurring in nature (wow!) • Repressilator • Actualprogrammed systems (boring) • Shared bank account

14. Some observations • Concurrency is simpler! • Don’tneedexplicit ordering • The real world is not sequential • Trying to make it so is unnatural and hard • Try controlling a vehicle! • Concurrency is harder! • manypaths of computation (bank example) • Cannot debugbecausenon-deterministic so proofsneeded • Time, concurrency, communication are issues

15. History • 1950’s onwards • Read-compute-printrecords in parallel • Needs timing • 1960’s onward • slowi/o devices in parallel withfast and expensiveCPU • Interrupts, synchronisation, sharedmemory • Late 1960’s : timesharingexpensive CPU betweenusers • Modern laptop: backgroundcomputation from which the foreground process stealstime

16. How to structure all this?Answers from the 60’s • EachI/O devicecan be a process • Whatabout the CPU? • Eachdevice at least has a ”virtual process” in the CPU • Contextswitching • movenext process data into CPU • When? On time signal or ”interrupt” • How? CPU checks beforeeachinstruction • Whatdoeseach process need to know? • Whatdoes the system need to knowabouteach process?

17. Operating Systems (60’s thru 70’s) • Dividedintokernel and otherservices • whichrun as processes • The kernel provides • Handles the actual hardware • Implementsabstractions • Processes, with priorities and communication • Schedules the processes (usingtime-slicing or otherinterrupts) • A 90’s terminologyfootnote • Whena single OS process structuresitself as severalprocesses, these are called ”threads”

18. Interleaving • Each process executes a sequence of atomiccommands (usuallycalled ”statements”, though I don’t like that term). • Each process has itsowncontrol pointer, see 2.1 of Ben-Ari • For 2.2, seewhatinterleavings are impossible

19. State diagrams • In slides 2.4 and 2.5, note that the statedescribes variable valuesbefore the currentcommand is executed. • In 2.6, note that the ”statement” part is a pair, onestatement for each of the processes • Not all thinkablestates are reachable from the start state

20. Scenarios • A scenario is a sequence of states • A paththrough the state diagram • See 2.7 for an example • Eachrow is a state • The statement to be executed is in bold

21. Whyarbitraryinterleaving? • Multitasking (2.8 is a picture of a contextswitch) • Contextswitches are quiteexpensive • Takeplace on time slice or I/O interrupt • Thousands of process instructionsbetweenswitches • Butwhere the cut falls depends on the run • Runs of concurrent programs • Depend on exact timing of external events • Non-deterministic! Can’t debug the usualway! • Does different thingseach time!

22. The countingexample • Seealgorithm 2.9 on slide 2.24 • What are the min and max possiblevalues of n? • How to say it in C-BACI, Ada and Java • 2.27 to 2.32

23. Arbitraryinterleaving (contd.) • Multiprocessors (see 2.9) • If no contentionbetweenCPU’s • Trueparallelism (looks like arbitraryinterleaving) • Contentionresolvedarbitraril • Again, arbitraryinterleaving is the safestassumption

24. Butwhat is beinginterleaved? • Unit of interleavingcan be • Wholefunctioncalls? • High levelstatements? • Machineinstructions? • Largerunitslead to easierproofsbut make otherprocesseswaitunnecessarily • Wemightwant to change the units as wemaintain the program • Hence best to leavethingsunspecified

25. Why not rely on speed throughout? • Don’t get into the traincrash scenario • use speed and time throughout to design • everydayplanning is often like this • Particularly in older, simplermachineswithout sensors • For people, wealsoadd explicit synchronisation • For our programs, the input can come from the keyboard or broadband • And the broadband gets faster everyfewmonths • So allowarbitrary speeds

26. Atomic statements • The thing that happenswithoutinterruption • Can be implemented as high priority • Comparealgorithms 2.3 and 2.4 • Slides 2.12 to 2.17 • 2.3 canguarantee n=2 at the end • 2.4 cannot • hardware folk saythere is a ”race condition” • We must saywhat the atomicstatements are • In the book, assignments and booleanconditions • How to implementthese as atomic?

27. What are hardware atomicactions? • Setting a register • Testing a register • Is that enough? • Thinkabout it (or cheat, and read Chap. 3)

28. The standard Concurrencymodel • What world are weliving in, or choose to? • Synchronous or asynchronous? • Real-time? • Distributed? • Wechoose an abstraction that • Mimicsenough of the real world to be useful • Has niceproperties (canbuilduseful and good programs) • Can be implementedcorrectly, preferablyeasily

29. Obey the rules you make! • For almost all of this course, weassumesingle processor withoutreal-time (so parallelism is only potential). • Real life examplewhere it is dangerous to make time assumptionswhen the system is designed on explicit synchronisation – the train • And at leastknow the rules! (Therac).

30. Terminology • A ”process” is a sequentialcomponent that mayinteract or communicate with otherprocesses. • A (concurrent) ”program” is builtout of componentprocesses • The componentscanpotentiallyrun in parallel, or may be interleaved on a single processor. Multiple processors mayallowactualparallelism.

31. Goals of the course • covers parallelprogrammingtoo – but it will not be the focus of this course • Understanding of a range of programminglanguageconstructs for concurrentprogramming • Ability to applythese in practice to synchronisation problems in concurrentprogramming • Practicalknowledge of the programmingtechniques of modern concurrentprogramminglanguages

32. Theoreticalcomponent • Introduction to the problems common to manycomputingdisciplines: • Operating systems • Distributed systems • Real-time systems • Appreciation of the problems of concurrentprogramming • Classic synchronisation problems

33. Semantics • Whatdo you want the system to do? • Howdo you know it does it? • Howdo you evensaythesethings? • Various kinds of logic • Build the right system (Validate the spec) • Build it right (verify that system meetsspec)