Concurrent Programming Is Easy Bertrand Meyer ETH Zurich & - PowerPoint PPT Presentation

Chair of Software Engineering Concurrent Programming Is Easy Bertrand Meyer ETH Zurich & Eiffel Software Future Of Software Engineering ETH Zurich Symposium, November 2010

Two topics 1. Concurrent Programming Is Easy 2. Developments at the Chair of Software Engineering: an overview 2

Moore‘s Law Transistor count still rising Clock speed flattening sharply Source: Intel 3

Concurrency Multicore, Internet, high-performance computing… Multi-core processing is taking the industry on Faster Chips Are a fast-moving and exciting ride into profoundly Leaving new territory. The defining paradigm in Programmers in computing performance has shifted inexorably Their Dust (John from raw clock speed to parallel operations and Markoff, NY energy efficiency. (Intel) Times, 2007) Multicore processors represent Multicore: This is the one of the largest technology one which will have the transitions in the computing biggest impact on us. industry today, with deep We have never had a implications for how we develop problem to solve like software. (Rick Rashid) this. A breakthrough is needed. (Bill Gates) 4

Concurrent programming is supposed to be hard… 5

The chasm CSP, Source: A.W. Roscoe Qsort = last → end → Qsort □ in?x → ((IN x // up:Qsort) //down:Qsort) In x = in?y → ((up.in!y → IN x ) <y > x> (down.in!y → IN x )) | | □ last → up.last → down.last → OUTA x OUTA x = up.out?y → out!y → OUTA x □ up.end → out!x → OUTB OUTB = down.out?y → out!y → OUTB □ down.end → end → X X = last → end → X □ in?x → IN x 6

The chasm 7

Wrong assumptions “ Objects are naturally concurrent ” (Milner)  Many attempts, often based on “Active objects” (a self-contradictory notion)  Lead to artificial issue of “Inheritance anomaly” “ Concurrency is the basic scheme, sequential programming a special case ” (many)  Correct in principle, but in practice we understand sequential best 8

Active objects can be programmed deferred class PROCESS feature live do from setup until over loop step end tear_down end over: BOOLEAN deferred end setup deferred end step do end tear_down deferred end end 9

SCOOP mechanism Piotr Nienaltowski, Benjamin Morandi, Sebastian Nanz, Scott West, Volkan Arslan (Eiffel Software: Emmanuel Stapf, Alexander Kogtenkov, Ian King) Simple Concurrent Object-Oriented Programming CACM (1993) & Object-Oriented Software Construction , 1997 Prototype implementation at ETH (since 2007); production version at Eiffel Software, released in steps starting November 2010 Most up-to-date descriptions:  Piotr Nienaltowski’s 2007 ETH PhD dissertation, see http://se.ethz.ch/people/nienaltowski/papers/thesis.pdf  Benjamin Morandi, Sebastian S. Bauer and Bertrand Meyer SCOOP - A contract-based concurrent object-oriented programming model , in Proc. of LASER summer school on Software Engineering 2007/2008 , ed. P. Müller, LNCS 6029, Springer-Verlag, July 2010, pages 41-90, see http://se.ethz.ch/~meyer/publications/concurrency/scoop_laser.pdf 10

What we write in sequential code transfer (source, target: separate ACCOUNT; value: INTEGER) require source . balance >= value do source . withdraw (value) target . deposit (value) ensure source . balance = old source . balance - value target . balance = old target . balance + value end invariant balance >= 0 11

A better version transfer (source, target: separate ACCOUNT; value: INTEGER) require source . balance >= value do source . withdraw (value) target . deposit (value) ensure source . balance = old source . balance - value target . balance = old target . balance + value end … invariant balance >= 0 12

Make this concurrent! transfer (source, target: separate ACCOUNT; value: INTEGER) require source . balance >= value do source . withdraw (value) target . deposit (value) ensure source . balance = old source . balance - value target . balance = old target . balance + value end … invariant balance >= 0 13

Dining philosophers 14

Dining philosophers in SCOOP class PHILOSOPHER inherit PROCESS rename setup as getup redefine step end feature { BUTLER } step do think ; eat ( left , right ) end eat ( l , r : separate FORK ) -- Eat, having grabbed l and r . do … end end 15

put my_queue : [T ] QUEUE BUFFER item, remove … if not my_queue . is_full then put (b : [G ] ; v : G ) BUFFER QUEUE -- Store v into b. require put (my_queue, t ) not b . is_full end do … ensure not b . is_empty b . item = v end 16

Reasoning about objects: sequential {INV and Pre r } body r {INV and Post r } ___________________________________ {Pre r ’ } x . r (a) {Post r ’ } Only n proofs if n exported routines! Priming represents actual-formal argument substitution 17

In a concurrent context Only n proofs if n exported routines? Client 3 Client 2 Client 1 r3 r2 r1 No overlapping! {INV and Pre r } body r {INV and Post r } ___________________________________ {Pre r ’} x . r (a) {Post r ’} 18

SCOOP rules  One processor per object: “handler”  At most one feature (operation) active on an object at any time 19

Object-oriented computation To perform a computation is  To apply certain actions  To certain objects  Using certain processors Objects Actions Processor 20

What makes an application concurrent? Processor : Thread of control supporting sequential execution of instructions on one or more objects Can be implemented as: Objects Actions  Computer CPU  Process  Thread Processor  … 21

Feature call: sequential x . r ( a ) Client Supplier previous r ( x : A ) x . r ( a ) do … end next Processor 22

Feature call: asynchronous Client Supplier previous r ( x : A ) x . r ( a ) do … end next Supplier’s handler Client’s handler 23

The fundamental difference To wait or not to wait:  If same processor, synchronous  If different processor, asynchronous Difference must be captured by syntax:  x: T  x: separate T -- Potentially different processor Fundamental semantic rule: x . r ( a ) waits for non- separate x , doesn’t wait for separate x . 24

put my_queue : [T ] QUEUE BUFFER item, remove … The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again. if not my_queue . is_full then put (b : [G ] ; v : G ) BUFFER QUEUE -- Store v into b. require put (my_queue, t ) not b . is_full end do … ensure not b . is_empty b . item = v end 25

Synchronization rule A call with separate arguments waits until:  The corresponding objects are all available  Preconditions hold It will hold the arguments for the duration of the routine’s execution “Separate call”: x . f ( a ) -- where a is separate 26

Dining philosophers class PHILOSOPHER inherit PROCESS rename setup as getup redefine step end feature { BUTLER } step do think ; eat ( left , right ) end eat ( l , r : separate FORK ) -- Eat, having grabbed l and r . do … end end 27

Bank transfer transfer (source, target: separate ACCOUNT; value: INTEGER) require source . balance >= value do source . withdraw (value) target . deposit (value) ensure source . balance = old source . balance - value target . balance = old target . balance + value end … invariant balance >= 0 28

Resynchronization Denis Caromel (Nice) No explicit mechanism needed for client to resynchronize with supplier after separate call. The client will wait only when it needs to: x . f x . g ( a ) y . f Wait here! … value := x . some_query 29

Refined proof rule (partial correctness) Piotr Nienaltowski {INV ∧ Pre r (x)} body r {INV ∧ Post r (x)} {Pre r (a cont )} x . r (a) {Post r (a cont )} Hoare-style sequential reasoning Controlled expressions are locked by current processor

Elevator example architecture Client Inheritance For maximal concurrency, all objects are separate 31

Two topics 1. Concurrent Programming Is Easy 2. Developments at the Chair of Software Engineering: an overview 32

Funding ETH Swiss National Science Foundation Hasler Stiftung Gebert-Ruf Stiftung 33

Verification As a Matter of Course Sep. Auto. Alias Inter. Invariant AutoFix prover prover prover analysis inference Arbiter Suggestions Programmer Test EVE execution Test case generation Suggestions AutoTest Test results

Unifying framework: Eiffel Method and language Language is ECMA- and ISO-standardized Full object-oriented model Built-in contracts Void safety (no null pointer dereferencing) Extensive development environment (EiffelStudio) 35

Push-button testing: AutoTest I.Ciupa, A. Leitner, M. Oriol, Now part of EiffelStudio A. Pretschner, E. Stapf, Yi Wei…  Test generation:  Fully automatic generation of test cases  Oracles are contracts  Integration with regression testing  Found hundreds of bugs in libraries & apps  Test extraction: generate tests from failures  Manual testing (à la Junit) 36

Faults found per second Faults fc (t) Time 37