Concurrent programming is easy Bertrand Meyer Kirkland, WG 2.3, July 2012

transcript

Chair of Software Engineering

Concurrent programming is easy

Bertrand Meyer

Kirkland, WG 2.3, July 2012

You mean

he is actually getting

ERC money

What this is about

SCOOP: a model for bringing concurrent programming under control

Not new (goes back to 90s)

But in recent years has been patiently refined (PhD theses) and implemented (now part of standard EiffelStudio)

And is receiving a new impetus

The issue that SCOOP tackles

Can we bring concurrent programmingto the same level

of abstraction and convenienceas sequential programming?

Two key goals

1. Retain the modeling power of object-oriented programming, in its Eiffel variant with contracts

2. Retain “reasonability”

Dijkstra 68

... [O]ur intellectual powers are rather geared to master static relations and our powers to visualize processes evolving in time are relatively poorly developed.

For that reason we should do ... our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.

Concurrent programming today

Allen Downey: The Little Green Book of Semaphores, greenteapress.com/semaphores/

Reasoning from APIs

transfer (source, target: ACCOUNT;amount: INTEGER)

-- Transfer amount from source to target.require

source balance >= amount do

source withdraw (amount)target deposit (amount)

ensuresource balance = old source balance –

amounttarget balance = old target balance +

amountend

invariantbalance >= 0

Reasoning from APIs

amountend

Reasoning from APIs if acc1.balance >= 100 then transfer (acc1, acc2, 100) end

amountend

if acc1.balance >= 100 then transfer (acc1, acc3, 100) end

invariantbalance >=

Example 2: hexapod robot

Hind legs have force sensors on feet and retraction limit switches

Hexapod locomotion

Alternating protraction and retraction of tripod pairs Begin protraction only if partner legs are down Depress legs only if partner legs have retracted Begin retraction when partner legs are up

Ganesh Ramanathan, Benjamin Morandi, IROS 2011

Hexapod coordination rulesR1: Protraction can start only if partner group on groundR2.1: Protraction starts on completion of retractionR2.2: Retraction starts on completion of protractionR3: Retraction can start only when partner group raisedR4: Protraction can end only when partner group retracted

Dürr, Schmitz, Cruse: Behavior-based modeling of hexapod locomotion: linking biology & technical application, in Arthropod Structure & Development, 2004

Sequential implementation

Multi-threaded implementation

Hexapod coordination rulesR1: Protraction can start only if partner group on groundR2.1: Protraction starts on completion of retractionR2.2: Retraction starts on completion of protractionR3: Retraction can start only when partner group raisedR4: Protraction can end only when partner group retracted

Dürr, Schmitz, Cruse: Behavior-based modeling of hexapod locomotion: linking biology & technical application, in Arthropod Structure & Development, 2004

SCOOP version

begin_protraction (partner, me: separate LEG_GROUP)

requireme legs_retractedpartner legs_downnot partner protraction_pending

dotripod liftme set_protraction_pending

The design of SCOOP (and this presentation)

To achieve the stated goals, SCOOP makes a number of restrictions on the concurrent programming model

This presentation explains these restrictions

The goal is not to limit programmers but to enable them to reason about their programs

Handling concurrency simply

SCOOP narrows down the distinction between sequential & concurrent programming to six properties, studied next:

(A) Single vs multiple “processors” (B) Regions (C) Synchronous vs asynchronous calls (D) Semantics of argument passing (E) Semantics of resynchronization (lazy wait) (F) Semantics of preconditions

The starting point (A): processors

To perform a computation is To apply certain actions To certain objects Using certain processors

Processor

Actions Objects

Sequential: one processorConcurrent: any number of

processors

What makes an application concurrent?Processor:Thread of control supporting sequential execution of instructions on one or more objects

Can be implemented as: Computer CPU Process Thread

The SCOOP model is abstract and does not specify the mapping to such actual computational resources

Processor

Actions Objects

Object-oriented programming

The key operation is “feature call”

x f (args)

where x, the target of the call, denotes an object to which the call will apply the feature f

Which processor is in charge of executing such a call?

(B): Regions

All calls targeting a given object will be executed by a single processor

The set of objects handled by a given processor is called a region

The processor in charge of an object is its handler

Reasoning about objects: sequential

{INV and Prer } bodyr {INV and Postr }___________________________________

{Prer’ } x.r (a) {Postr’ }

Priming represents actual-formal

argument substitution

Only n proofs if n exported routines!

The concurrent version of this rule will come later!

In a concurrent contextOnly n proofs if n exported routines?

{Prer’} x.r (a) {Postr’}

Client 1

Client 2

Client 3

No overlapping!

Reasonability

SCOOP restriction: one handler per object

One processor per object: “handler”

At most one feature (operation) active on an object at any time

Reasonability

Regions

The notion of handler implies a partitioning of the set of objects:

The set of objects handled by a given processor is called a region

Handler rule implies one-to-one correspondence between processors and regions

An aside: processor collection

Processors, like objects, can become unreachable!Object and processor collection is intertwined

LO = s* (BR r (LP))

LP = BP h (LO)

Alexander Kogtenkov, MSEPT 2012

Live objects

Live processors Basic

processors

Basic roots

Root objects

Handler

References

(C) The sequential view: O-O feature calls

x.r (a)

Processor

Client Supplier

r (x : A)do

…end

(C) The concurrent form of call: asynchronous

Client Supplier

r (x : A)do

…end

Client’s handler Supplier’s handler

The two forms of O-O call

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: a call x.r (a)Waits (i.e. is synchronous) for non-separate

xDoes not wait (is asynchronous) for

separate x

Reasonability

Why potentially separate?

separate declaration does not specify processor: only states that the object might be handled by a different processor

In class A: x: separate B In class B: y: separate A

In some execution the value of x.y might be a reference to an object in the current region (including Current itself)

Call vs application

With asynchrony we must distinguish between feature call and feature application

The execution of

x r (...)

is the call, and (with x separate) will not wait (the client just logs the call)

The execution of r happens later and is called the feature application

Consistency rules: avoiding traitors

nonsep : T

sep : separate T

nonsep := sep

nonsep.p (a)

Traitor!

Traitor avoidance: Piotr Nienaltowski’s type system for SCOOP

Reasonability

(D) Access control policy

Since separate calls are asynchronous there is a real danger of confusion

Consider:

Reasonability

my_stack : separate STACK [T ]…my_stack.put (a)… Instructions not affecting

stack… y := my_stack.item

some_routine (

(D) Access control policy

SCOOP requires the target of a separate call to be a formal argument of enclosing routine:

Reasonability

my_stack : separate STACK [T ]…my_stack.put (a)… Instructions not affecting

stack… y := my_stack.item

(D) Separate argument rule

The target of a separate callmust be an argument of the enclosing routine

Separate call: x.f (...) where x is separate

(D) Wait rule

A routine call guarantees exclusive access to the

handlers (the processors) of all separate arguments

some_routine (nonsep_a, nonsep_b, sep_c, sep_d, sep_e )

Exclusive access to sep_c, sep_d, sep_e within a_routine

Reasonability

Dining philosophers in SCOOP (1)

class PHILOSOPHER featurelive

dofrom getup until over

loop think ; eat (left, right)

endend

eat ( l, r : separate FORK ) -- Eat, having grabbed l and r.

do … end

getup do … endover : BOOLEAN

Traditional code

Dining philosophers in SCOOP (2)

class PHILOSOPHER inheritREPEATABLE

rename setup as getupredefine step end

feature {BUTLER}step

do think ; eat (left, right)

eat (l, r : separate FORK) -- Eat, having grabbed l and r.

do … endend Reasonability

The general notion of processSCOOP integrates inheritance and other O-O techniques with concurrency, seamlessly and without conflicts (“inheritance anomaly”)No need for built-in notion of active object: it is programmed through a library class such as :

class REPEATABLE featuresetup do endstep do endover : BOOLEANtear_down do endlive

dofrom setup until over loop step endtear_down

endend

end 42

(D) What the wait rule means

Beat enemy number one in concurrent world: atomicity violations

Data races Illegal interleaving of calls

Data races cannot occur in SCOOP

Semantics vs implementationOlder SCOOP literature says that feature application “waits” until all the separate arguments’ handlers are availableThis is not necessary!What matters is exclusive access: implementation does not have to wait unless semantically necessaryThe implementation performs some of these optimizations

f (a, b, c : separate T)do

something_elsea rb s

No need to wait for a and b until here

No need to wait for c!

(D) Wait rule

A routine call guarantees exclusive access to the

handlers (the processors) of all separate arguments

some_routine (nonsep_a, nonsep_b, sep_c, sep_d, sep_e )

Exclusive access to sep_c, sep_d, sep_e within a_routine

(E) Resynchronization: lazy wait (Caromel)

How do we resynchronize after asynchronous (separate) call?No explicit mechanism!The client will wait when, and only when, it needs to:

x fx g (a)y f…value := x.some_query

Lazy wait (also known as wait by necessity)

Wait here!

Reasonability

(E) Synchrony vs asynchrony revisited

For a separate target x:

x command (...) is asynchronous

v := x query (...) is synchronous

What becomes of contracts, in particular preconditions, in a concurrent context?

(F) Contracts

Preconditions as wait conditions if acc1 balance >= 100 then transfer (acc1, acc2, 100) end

amountend

if acc1 balance >= 100 then transfer (acc1, acc3, 100) end separat

put (b : separate QUEUE [INTEGER ] ; v : INTEGER) -- Store v into buffer b.

requirenot b.is_fulli > 0

dob.put (i )

ensurenot b.is_empty

...put (my_buffer, 10 )

(F) Contracts

Precondition becomes wait condition

(F) Full synchronization rule

A call with separate arguments waits until:

The caller can get exclusive access to their processors

Preconditions hold

“Separate call”:

x.f (a) -- where a is separate Reasonability

Generalized semantics of preconditions

The different semantics is surprising at first: Separate: wait condition Non-separate: correctness condition

At a high abstraction level, however, we may consider that

Wait semantics always applies in principle

Sequentiality is a special case of concurrency

Wait semantics boils down to correctness semantics for non-separate preconditions.

Smart compiler can detect some cases Other cases detected at run time

Reasoning about objects: sequential

{Prer’ } x.r (a) {Postr’ }

Only n proofs if n exported routines!

Refined proof rule (partial correctness)

{INV Prer (x)} bodyr {INV Postr (x)}

{Prer (a cont)} e.r (a) {Postr (a cont)}

Hoare-style sequential reasoning

Controlled expressions (known statically as part of the type system) are:

Attached (statically known to be non-void) Handled by processor locked in current

context

Status All of SCOOP as described here implemented Available as part of standard EiffelStudio

download

Download: www.eiffel.com

SCOOP highlights Close connection to O-O modeling Natural use of O-O mechanisms such as inheritance Built-in guarantee of no data races & fairness Removes many concerns from programmer Supports many different forms of concurrency Retains accepted patterns of reasoning about

programs Simple to learn and use (e.g. all standard

concurrency examples)

Reasonability

Limitations & current workModel & theory

Deadlock detection -- through alias analysis Multiple readers -- pure queries Exceptions Distribution Transactions Real-time Proofs

Implementation & applications Lazy locking Performance More tools (profiling, debugging…) Real-time High-performance computing Large applications

se.ethz.ch/research/scoop.html

Concurrent programming is easy Bertrand Meyer Kirkland, WG 2.3, July 2012

Documents