dependent types for high-confidence distributed systems
Post on 01-Jan-2016
29 Views
Preview:
DESCRIPTION
TRANSCRIPT
Dependent Types for High-Confidence Distributed
Systems
Paul Sivilotti - Ohio StateHongwei Xi – Cincinnati
(Boston Univ.)
Specifying and Testing Quantified Progress Properties 2
Gaining confidence that program text satisfies required behavior
Two Challenges Specifying com-
ponent behavior and reasoning about its com-position
SystemProperties
Component AProperties
Component BProperties
Component CProperties
Component AProgram Text
Component B Program Text
Component C Program Text
Specifying and Testing Quantified Progress Properties 3
Dependent Types enriched types familiar, low cost
Two Synergistic Solutions
Synergy: locality Surprising Connection: termination
Certificates temporal logic local properties
Typically not used for reasoning about progress
Typically not tied to real programs
Specifying and Testing Quantified Progress Properties 4
Talk Outline Background and Motivation Phase I: foundational
Dependent types for metrics local termination
Certificates for progress with metrics functional transient, functional next
Phase II: integration DXanadu: a distributed dependently
typed language
Phase I
Dependent Types for Metrics
Specifying and Testing Quantified Progress Properties 6
Dependent Types Dependent types are types that
can depend on the values of expressions
Examples int(i) is a singleton type that contains
the only integer equal to i int array(n) is the type for integer
arrays of size n
Specifying and Testing Quantified Progress Properties 7
Metrics and Integer Constraints Index variables and expressions
i+j, i-j, i*j, i/j, … Let = <i1,...,in> be a tuple of
index expressions. We write : metric if we have ij:nat for 1 j n Lexicographic ordering Well-founded
Specifying and Testing Quantified Progress Properties 8
McCarthy’s 91 Function
{i:nat} <max(0, 101-i)> =>[j:int | (i <= 100 j = 91) (i > 100 j = i-10)]
int(j)ninetyone (x:int(i)) { if (x <= 100) { return ninetyone (ninetyone (x+11)); } else { return (x-10); }}
Specifying and Testing Quantified Progress Properties 9
Cost Effectiveness In general, termination of a
program is difficult to prove However, critical sections tend to
be small and manageable More importantly, we provide the
programmer with a range of choices higher effort lower effort higher benefit lower benefit
Specifying and Testing Quantified Progress Properties 10
Spectrum of Choices Static Check
Programmer provides a metric Type-checker verifies monotonicity of metric
Dynamic Check Programmer provides a metric Type-checker inserts run-time tests to check
monotonicity of metric Checkpointing
Programmer does not provide a metric Checkpoint taken before “dangerous” action
Specifying and Testing Quantified Progress Properties 11
Bit Reversing from FFT
{a:nat,b:pos} <max(0, a-b)> => intbitrev (j:int(a),k:int(b)) { if (k < j) { return bitrev (j-k,k/2); } else { return j+k; }}
Specifying and Testing Quantified Progress Properties 12
Bit Reversing from FFT
{a:nat,b:pos} <max(0, a-b)> => intbitrev (j:int(a),k:int(b)) { if (k < j) { assert (k > 1); return bitrev (j-k,k/2); } else { return j+k; }}
Phase I
Functional Certificates
Specifying and Testing Quantified Progress Properties 14
Transient P for component C means: progress: if P ever becomes true, it
eventually becomes false locality: guaranteed by an action of C
alone More formally:
transient P a C : [ P wp.a.P ]
“Transient”: A Certificate for Progress
Specifying and Testing Quantified Progress Properties 15
E.g.: Mutual Exclusion
System: every client request is eventually satisfied
Token-passingLayer
Client CClient D
Client E
Client B
Client A
Client: token is eventually returned transient holding
Specifying and Testing Quantified Progress Properties 16
Client Program
To prove transient holding, show CS terminates (ie ninetyone terminates)
*[ non CS ! request ? token //holding is true CS: ninetyone(0); ! token //holding is false ]
Specifying and Testing Quantified Progress Properties 17
Testing Transience Recall for transient.P:
If P ever becomes true, it is later false Note: P may never become true
Consequence of formal definition:transient.P infinitely often P
To test for transience, use:transient.P finitely often P Look for a finite trace after which only
P
Specifying and Testing Quantified Progress Properties 18
Timestamped History
transient.P
true
false
P
timedanger dangerdanger
P
settimestamp
cleartimestamp
predicate evaluation…
Specifying and Testing Quantified Progress Properties 19
Multiple Properties A component may have many
progress propertiestransient.(status = critical)transient.(status = idle ^ button_down)transient.( . . . )
Specifying and Testing Quantified Progress Properties 20
Multiple Transient Prop’stransient.P ^ transient.Q ^ transient.R
Complexity: Space: n timestamps kept Time: n predicate evaluations with each step
P
Q
R
Specifying and Testing Quantified Progress Properties 21
Quantification of Transient Transient properties often quantified
“state changes eventually”Ak :: transient.(status = k)
“value of metric changes eventually”Ak :: transient.(metric = k ^ status = critical)
Naïve expansion is costly to monitor If dummy ranges over a set D of values:
|D| timestamps to maintain |D| predicate evaluations to perform
Specifying and Testing Quantified Progress Properties 22
Observation: Singularity Predicates are mutually exclusive Ak :: transient.(metric = k ^ status = critical) (P)
= transient.(metric = 0 ^ status = critical) (P0)
^ transient.(metric = 1 ^ status = critical) (P1) ^ transient.(metric = 2 ^ status = critical)… (P2)…
Truth of predicate functionally determines value of dummy variableFor P.(s,k) : predicate on state s, dummy k:
Ak :: transient.(P.(s,k)) is functional iffEf :: (P.(s,k) k = f.s)
Specifying and Testing Quantified Progress Properties 23
Functional TransienceAk :: transient.(metric = k ^ status =
critical)
When is there “danger” of a possible violation?
P0
P1
P2
P3
Specifying and Testing Quantified Progress Properties 24
Satisfying Functional Transience A functional transient property is
“satisfied” when either: The predicate that is true changes
Value(s) of dummy variable(s) that makes predicate true changes
All predicates become false Provide f: states dummy values
Evaluate k using f Evaluate P using k
Specifying and Testing Quantified Progress Properties 25
Functional TransienceAk :: transient.(metric = k ^ status =
critical)
Complexity: Space: 1 timestamp & value(s) of dummy(s) Time: 1 function & 1 predicate evaluation
P0
P1
P2
P3
TS S R R R CR S
Specifying and Testing Quantified Progress Properties 26
Generalization: Relational Transience Number of predicates that can be
simultaneously true is bounded (B)
Ak :: transient.(k <= metric <= k+1 ^ critical)
P0
P1
P2
P3
012
Specifying and Testing Quantified Progress Properties 27
Monitoring Relational Transience
Complexity Space: B timestamps & dummy values Time: 1 relation eval’n & 2B timestamp
updates
P0
P1
P2
P3
TS1
TS0
S
S
R R C
R R
S C
C S
Specifying and Testing Quantified Progress Properties 28
Ubiquity of Functional Transience Observation: Many quantifications
of transient appear to be functional E.g., timeouts and metrics
Method-response semantics “method M returns a value eventually”
Ak :: transient.(rcv_M = k+1 ^ snd_M = k)Ak :: transient.(rcv_M > k ^ snd_M = k)Ajk : j > k : transient.(rcv_M = j ^ snd_M = k)
Specifying and Testing Quantified Progress Properties 29
Other Progress Operators Transient is a very basic operator
Nice compositional properties Higher-order operator: leads-to (+-
>) Testing leads-to does not always
benefit from notion of functionality E.g., (Ak :: x = k +-> y = k)
Other simplifications can be made (Ak :: x = k +-> x < k)
Specifying and Testing Quantified Progress Properties 30
Quantification of Safety Properties Safety operator: P next Q
“if P holds, Q holds in the next state” Similar quantifications arise
Ak :: x = k next x <= k Also commonly functional
Truth of pre-predicate determines value(s) of dummy(s)
Similar performance benefit 1 function & 1 predicate evaluation
Phase II
DXanadu: A distributed dependently-typed language
Specifying and Testing Quantified Progress Properties 32
DXanadu Integration: dependent types and
distributed programming Metrics for termination and progress Certificates for specs and reasoning
Implementation test bed
Specifying and Testing Quantified Progress Properties 33
Communication Primitives Sequential Xanadu augmented with
send() and receive() keywords Point-to-point communication, with
fair merge at destination unit send(m,d)
m : basic type, arrays, non-nested records d : integer id of destination node
m = receive() Asynchronous send, blocking receive
Specifying and Testing Quantified Progress Properties 34
Architecture Java RMI for communication backbone
Serialization of message types Static bootstrapping and component binding
DXanadu #0
DXanadu #1
DXanadu #2
POBox A
DXanadu #3
POBox B
DXanadu #4
POBox C
PostCentral
java
ocaml
Specifying and Testing Quantified Progress Properties 35
Challenges to Be Faced Message typing
Dynamic structures (nesting, lists) Preserving (dependent) type information
Fault tolerance Conservative checkpointing for rollback
Linking code with certificate spec Run-time tests for validation
Dynamic computations Discovery, binding, departure
Experimentation with DXanadu
Specifying and Testing Quantified Progress Properties 36
Papers Acknowledging OBR LICS 01: “Dependent Types for Program
Termination Verification” FSE 01: “Increasing Client-Side Confidence in
Remote Component Implementations” ICFP 01: “A Dependently-Typed Assembly
Language” ICSE 01: “The Specification and Testing of
Quantified Progress Properties in Distributed Systems”
J. of Applied Systems Studies: “Testing the Protocol Conformance of Distributed components” (submitted)
Dependent Types for High-Confidence Distributed
Systems
Paul Sivilotti - Ohio StateHongwei Xi – Cincinnati
(Boston Univ.)
top related