C LAUS B RABRAND © C ONCURRENCY (Q3,’06) J AN 19, 2006 C ONCURRENCY Claus Brabrand [ ]

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) J AN 19, 2006 W ELCOME !

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 3 ] J AN 19, 2006 Agenda (Course Presentation) Course Presentation (from Homepage): Aims & Goals Exam (assessment & format) Motivation: ” Why bother learning about Concurrency!?!” Roles (students & teachers) Program (course schedule & weekly schedule) Materials (book & notes) Week 1: ”Processes and Threads” Concepts Models (FSP) Practice (Java) Models (FSP)  (Java) Practice

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 4 ] J AN 19, 2006 Weekly Schedule Lectures: Mondays 12:15-15:00 (sometimes a bit less) Practical Programming Labs (aka. “Lab”): Wednesdays 11:15-13:00 [ zuse.127 ] Theoretical Exercise Classes (aka. “TØ”): Wednesdays 13:15-15:00 [ codd-s.121 ] Studying: Exercises, Reading, and Thinking(!) Compulsory homework: Hand-ins (Sunday deadlines), Mini-project 3 hrs/week 2 hrs/week ? hrs/week Expected total: 15 hrs/week

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 5 ] J AN 19, 2006 Concurrency: Aims & Goals Exam Motivation Roles Program Project Exam Materials Classes Webboard Homepage [ ]

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) J AN 19, 2006 Y OUR R OLE (C ONT ’ D ) Active Learning (!)

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 7 ] J AN 19, 2006 Consider the following “alphabet” (60 secs): Exercise: Now write my office phone#: ? Exercise

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 8 ] J AN 19, 2006 Exercise 1 (cont’d) Suppose I now showed you…: Exercise: Now write my office phone#: ?

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 9 ] J AN 19, 2006 Exercise 1 (cont’d) So what is the point? Random information is really hard to remember We learn (efficiently) by associating (building) new unknown information / with (on) old known information Knowledge is constructed as a result of: Learner’s activity (!) In short: “You need to study”: i.e. read, make exercises, and think(!)

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) J AN 19, 2006 C OLLABORATION Teaching / Learning Collaboration

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 11 ] J AN 19, 2006 Roles (Teaching/Learning Collaboration) During learning period (i.e., before the exam): Teaching/Learning collaboration: You = “Learner” Learning responsibility Me = “Teacher” (and Teaching Assistant) (To the best of my ability) aid you in learning During the exam period: You = “Performer” Demonstrate what you have learned Me = “Evaluator” (Neutrally) assess your level of understanding

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) J AN 19, 2006 M OTIVATION “Why bother learning about Concurrency?!?”

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 13 ] J AN 19, 2006 What is a Concurrent Program? A sequential program has a single thread of control A concurrent program has multiple threads of control: Perform multiple computations in parallel Control multiple external activities which occur at the same time

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 14 ] J AN 19, 2006 Why Concurrent Programming? More appropriate program structure Concurrency reflected in program Performance gain from multiprocessing HW Parallelism Increased application throughput An I/O call need only block one thread Increased application responsiveness High-priority thread for user requests

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 15 ] J AN 19, 2006 Concurrency vs. Sequentiality Sequential programming: Inherently deterministic Describe computation as a “reduction” of expressions to values Termination often desirable Resulting value is of primary interest and focus Concurrent programming: Inherently non-deterministic Describe execution as “process evolution” Describe possible executions (aka. execution traces) Describe possible interactions during execution Describe interaction with an environment Non-termination often desirable (e.g. Op.Sys., Control sys, Cell-phone, …) Resulting “value” is not (necessarily) interesting

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 16 ] J AN 19, 2006 Concurrency is much Harder Harder than sequential programming: Huge number of possible executions Inherently non-deterministic Parallelism conceptually harder Consequences: Programs are harder to write(!) Programs are harder to debug(!) Errors are not always reproducible(!) New kinds of errors possible(!): Deadlock, starvation, priority inversion, interference, …

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 17 ] J AN 19, 2006 Example Concurrency Problems Therac-25 Radiation Therapy ’85-’87 Massive overdoses (6 deaths / amputations)! Mars Pathfinder July ’97 Periodic resets (on mars)! Win95/98 w/ 3 rd -Party Device Drivers late ’90es Dysfunction (“blue screen of death”)!

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 18 ] J AN 19, 2006 Concurrency Problems (cont’d) Mobile Phones ’00-… Freeze and odd behaviors (really annoying)! Cruise Control System Model ’86 [Grady Booch] Accellerated after car ignition (car crashes)!

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 19 ] J AN 19, 2006 …and what about? Air Plane Control System Dysfunction (plane crash)! Nuclear Powerplant Control System Core melt-down (“China-syndrome”)! … 

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 20 ] J AN 19, 2006 Problem: System Development? In the presence of all these errors: deadlock, starvation, priority inversion, interference, anti-cooperation, un-intended execution traces, un-fairness, … How to…: 1. …design a system that “works” ? 2. …verify that the system is “safe” ? 3. …verify that the system “meets its specification” ? …and: What does “works”, “safe”, and “to meet a specification” mean ?!?

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 21 ] J AN 19, 2006 Solution: Modeling “Models come to the rescue”: Create models (~ architecture, bridge construction, …) Formal modeling (e.g., “FSP”) permits: (Offline) Reasoning  understanding (Runtime) Testing  confidence (C-time) Property Verification  safety (C-time) Specification Verification  correctness Note: “Errors are much cheaper to commit in models than in implementations” “Never send a human to do a machine’s job” -- A.Smith (’99) auto- mate

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 22 ] J AN 19, 2006 Methodology: Model-based Design Design abstract model Decompose model Reason/Test/Verify model individual parts and whole Recompose insights make model safe Impl. concrete program concretize REAL PROBLEM SAFE MODEL SAFE PROGRAM abstract ? ? ? ? MODEL test reason verify

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 23 ] J AN 19, 2006 Program world Model world Concrete Abstract P M abstraction concretization Program vs. Model World (Java)(FSP) What discerns a really good programmer from one that is not so good is the capability of moving (consciously or unconsciously) between the concrete world of programs and the abstract world of semantic models (via abstraction and concretization). Specifically, such a programmer is capable of (consciously or unconsciously): - 1) abstracting programs into models - 2) reasoning about the models - 3) concretizing the insights back into the world of programs

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 24 ] J AN 19, 2006 Program world Model world Concrete Abstract P M 1. P  ?3. M  ? 4. validate 5. M  ! 7. P  ! 2. abstract 6. concretize Program / Model Verification (Java)(FSP)

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 25 ] J AN 19, 2006 Program world Model world Concrete Abstract ~ P P’ M M’ 1. P ~ P’ ? 2. abstract 3. M ~ M’ ? 4. relate 5. M ~ M’ ! 6. concretize 7. P ~ P’ ! Program / Model Relationship (Java)(FSP)

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 26 ] J AN 19, 2006 Glasses of Abstraction… It’s Amazing… Abstract away computational details: see only concurrency aspects at appropriate level of abstraction! Only $12,95 “See only the relevant!” “ The Glasses of Abstraction ” COMPLEX PROGRAM MODEL abstraction

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 27 ] J AN 19, 2006 Modeling: Level of Abstraction Consider a client/server system: Extremely abstract (high level of abstraction): Appropriate (level of abstraction) for … : Extremely concrete (low level of abstraction): Universe = (event -> Universe). NAND_Gate =... Transistor =... Accumulator = Client =... Server = (request->compute->reply->Server). Client = (calc->request->wait->reply->Client). Database =... higher level of abstraction

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 28 ] J AN 19, 2006 Notes on Skill Acquisition Your skill acquisition will progress according to the following stages of learning: 4. Unconscious competence 3. Conscious competence 2. Conscious incompetence 1. Unconscious incompetence Course aim (and measurement): Level 3 Later in life, you probably mostly need level 4 …but you need to get there via level 3

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 29 ] J AN 19, 2006 Modeling Language (e.g. “FSP”) Compositional:  || Break things into (several) smaller things Algebraic: ,  Intuitive ideal and eases automated verification Syntactic: Provide basis for programming languages P || QPQ big P || Q Q || P P || (Q || R) USER = def (acquire -> use -> release -> USER). (P || Q) || R

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 30 ] J AN 19, 2006 Parallel- vs. Concurrent Programming Strategy: Optimal strategy for a particular goal Use available resources efficiently Safety: Conceptually independent players Control interaction and “rules” The Football Match Analogy: “An analogy that one can make is with football*; - the coach of the team is a parallel programmer while - the referee is a concurrent programmer” -- [P.Panangaden, ’96] The Referee (~ the concurrent programmer): -- Make sure what is happening is a soccer match The Trainer (~ the parallel programmer): -- Make sure my agents are performing “optimally” */ interpret appropriately on either side of the Atlantic

C LAUS B RABRAND © C ONCURRENCY (Q3,’06) [ 31 ] J AN 19, 2006 Course Aims & Goals Your Aims & Goals: at huske udenad… at identificere brug af concurrency i (Java) programmer; at beskrive concurrency mekanismer i programmeringssprog (Java); at forklare fundamentale problemer, teknikker og løsninger indenfor concurrency; at forklare sammenhængen mellem modeller og programmer generelt; at relatere konkrete modeller og programmer; at sammenligne konkrete modeller; at ræsonnere om egenskaber af konkrete modeller og programmer; at implementere konkrete modeller i programmeringssprog (Java); at anvende ovenstående med henblik på at skabe konkrete modeller af systemer. T