Upload
gilead
View
36
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Concurrent programming is easy Bertrand Meyer Kirkland, WG 2.3, July 2012. h e is actually getting. You mean. ERC money. for. this?. What this is about. SCOOP: a model for bringing concurrent programming under control Not new (goes back to 90s) - PowerPoint PPT Presentation
Citation preview
Chair of Software Engineering
Concurrent programming is easy
Bertrand Meyer
Kirkland, WG 2.3, July 2012
You mean
he is actually getting
for
this?
ERC money
3
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
4
The issue that SCOOP tackles
Can we bring concurrent programmingto the same level
of abstraction and convenienceas sequential programming?
5
Two key goals
1. Retain the modeling power of object-oriented programming, in its Eiffel variant with contracts
2. Retain “reasonability”
6
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.
7
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
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
Reasoning from APIs if acc1.balance >= 100 then transfer (acc1, acc2, 100) end
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
if acc1.balance >= 100 then transfer (acc1, acc3, 100) end
invariantbalance >=
0
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
17
SCOOP version
begin_protraction (partner, me: separate LEG_GROUP)
requireme legs_retractedpartner legs_downnot partner protraction_pending
dotripod liftme set_protraction_pending
end
18
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
19
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
20
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
21
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
22
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
24
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!
25
In a concurrent contextOnly n proofs if n exported routines?
{INV and Prer } bodyr {INV and Postr }___________________________________
{Prer’} x.r (a) {Postr’}
Client 1
r1
Client 2
r2
Client 3
r3
No overlapping!
Reasonability
26
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
28
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
29
(C) The sequential view: O-O feature calls
x.r (a)
Processor
Client Supplier
previous
x.r (a)next
r (x : A)do
…end
30
(C) The concurrent form of call: asynchronous
Client Supplier
previous
x.r (a)next
r (x : A)do
…end
Client’s handler Supplier’s handler
31
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)
33
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
34
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
35
(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
36
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
)do
end
37
(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
38
(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
39
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
end
40
Traditional code
41
Dining philosophers in SCOOP (2)
class PHILOSOPHER inheritREPEATABLE
rename setup as getupredefine step end
feature {BUTLER}step
do think ; eat (left, right)
end
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
44
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
end
No need to wait for a and b until here
No need to wait for c!
45
(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
46
(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
47
(E) Synchrony vs asynchrony revisited
For a separate target x:
x command (...) is asynchronous
v := x query (...) is synchronous
48
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
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
if acc1 balance >= 100 then transfer (acc1, acc3, 100) end separat
e
50
put (b : separate QUEUE [INTEGER ] ; v : INTEGER) -- Store v into buffer b.
requirenot b.is_fulli > 0
dob.put (i )
ensurenot b.is_empty
end
...put (my_buffer, 10 )
(F) Contracts
Precondition becomes wait condition
51
(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
52
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
53
Reasoning about objects: sequential
{INV and Prer } bodyr {INV and Postr }___________________________________
{Prer’ } x.r (a) {Postr’ }
Only n proofs if n exported routines!
54
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
55
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
57
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