Type Soundness and Race Freedom for Mezzo

Size: px

Start display at page:

Download "Type Soundness and Race Freedom for Mezzo"

Elinor Rogers
5 years ago
Views:

1 Type Soundness and Race Freedom for Mezzo Thibaut Balabonski François Pottier Jonathan Protzenko INRIA FLOPS / 42

2 Mezzo in a few words Mezzo is a high-level programming language, equipped with: algebraic data types; first-class functions; garbage collection; mutable state; shared-memory concurrency Its static discipline is based on permissions 2 / 42

3 Permissions by example val r1 = newref () (* ref () *) 3 / 42

4 Permissions by example val r1 = newref () (* ref () *) val r2 = r1 (* ref () * =r1 *) 3 / 42

5 Permissions by example val r1 = newref () (* ref () *) val r2 = r1 (* ref () * =r1 *) (* ref () * r2 = r1 *) 3 / 42

6 Permissions by example val r1 = newref () (* ref () *) val r2 = r1 (* ref () * =r1 *) (* ref () * r2 = r1 *) val () = r1 := 0 (* ref int * r2 = r1 *) 3 / 42

7 Permissions by example val r1 = newref () (* ref () *) val r2 = r1 (* ref () * =r1 *) (* ref () * r2 = r1 *) val () = r1 := 0 (* ref int * r2 = r1 *) val x2 =!r2 + 1 (* ref int * r2 = r1 * int *) 3 / 42

8 Permissions by example val r1 = newref () (* ref () *) val r2 = r1 (* ref () * =r1 *) (* ref () * r2 = r1 *) val () = r1 := 0 (* ref int * r2 = r1 *) val x2 =!r2 + 1 (* ref int * r2 = r1 * int *) val p = (r1, r2) (* ref int * r2 = r1 * int * (=r1, =r2) *) 3 / 42

9 Permissions by example val r1 = newref () (* ref () *) val r2 = r1 (* ref () * =r1 *) (* ref () * r2 = r1 *) val () = r1 := 0 (* ref int * r2 = r1 *) val x2 =!r2 + 1 (* ref int * r2 = r1 * int *) val p = (r1, r2) (* ref int * r2 = r1 * int * (=r1, =r2) *) val () = assert (ref int, ref int) (* REJECTED *) 3 / 42

10 Permissions by example val r1 = newref () (* ref () *) val r2 = r1 (* ref () * =r1 *) (* ref () * r2 = r1 *) val () = r1 := 0 (* ref int * r2 = r1 *) val x2 =!r2 + 1 (* ref int * r2 = r1 * int *) val p = (r1, r2) (* ref int * r2 = r1 * int * (=r1, =r2) *) val () = assert (ref int, ref int) (* REJECTED *) val () = assert (r: ref int, =r) (* ACCEPTED *) 3 / 42

11 Permissions by example val r1 = newref () (* ref () *) val r2 = r1 (* ref () * =r1 *) (* ref () * r2 = r1 *) val () = r1 := 0 (* ref int * r2 = r1 *) val x2 =!r2 + 1 (* ref int * r2 = r1 * int *) val p = (r1, r2) (* ref int * r2 = r1 * int * (=r1, =r2) *) val () = assert (ref int, ref int) (* REJECTED *) val () = assert (r: ref int, =r) (* ACCEPTED *) val () = assert (=r, r: ref int) (* ACCEPTED *)

12 Permissions by example val r1 = newref () (* ref () *) val r2 = r1 (* ref () * =r1 *) Why do this? (* ref () * r2 = r1 *) val () = r1 := 0 (* ref int * r2 = r1 *) val x2 =!r2 + 1 (* ref int * r2 = r1 * int *) val p = (r1, r2) (* ref int * r2 = r1 * int * (=r1, =r2) *) val () = assert (ref int, ref int) (* REJECTED *) val () = assert (r: ref int, =r) (* ACCEPTED *) val () = assert (=r, r: ref int) (* ACCEPTED *)

13 Permissions by example val r1 = newref () (* ref () *) val r2 = r1 For fun and (* ref () * =r1 *) profit, of course! Why do this? (* ref () * r2 = r1 *) val () = r1 := 0 (* ref int * r2 = r1 *) val x2 =!r2 + 1 (* ref int * r2 = r1 * int *) val p = (r1, r2) (* ref int * r2 = r1 * int * (=r1, =r2) *) val () = assert (ref int, ref int) (* REJECTED *) val () = assert (r: ref int, =r) (* ACCEPTED *) val () = assert (=r, r: ref int) (* ACCEPTED *) 3 / 42

14 Motivation Imagine an imperative implementation of sets: val make: [a] () -> set a val insert: [a] (set a, consumes a) -> () val merge: [a] (set a, consumes set a) -> () 4 / 42

15 Motivation Imagine an imperative implementation of sets: val make: [a] () -> set a val insert: [a] (set a, consumes a) -> () val merge: [a] (set a, consumes set a) -> () Then, let s = make() in produces set t 4 / 42

16 Motivation Imagine an imperative implementation of sets: val make: [a] () -> set a val insert: [a] (set a, consumes a) -> () val merge: [a] (set a, consumes set a) -> () Then, let s = make() in produces set t cannot do merge(s, s); 4 / 42

17 Motivation Imagine an imperative implementation of sets: val make: [a] () -> set a val insert: [a] (set a, consumes a) -> () val merge: [a] (set a, consumes set a) -> () Then, let s = make() in produces set t cannot do merge(s, s); cannot do merge(s1, s2); insert(s2, x); 4 / 42

18 Motivation Imagine an imperative implementation of sets: val make: [a] () -> set a val insert: [a] (set a, consumes a) -> () val merge: [a] (set a, consumes set a) -> () Then, let s = make() in produces set t cannot do merge(s, s); cannot do merge(s1, s2); insert(s2, x); cannot do insert(s, x1) and insert(s, x2) in independent threads 4 / 42

19 Motivation Imagine an imperative implementation of sets: val make: [a] () -> set a val insert: [a] (set a, consumes a) -> () val merge: [a] (set a, consumes set a) -> () Then, error in sequential code: let s = make() in produces set t protocol violation cannot do merge(s, s); cannot do merge(s1, s2); insert(s2, x); cannot do insert(s, x1) and insert(s, x2) in independent threads 4 / 42

20 Motivation Imagine an imperative implementation of sets: val make: [a] () -> set a val insert: [a] (set a, consumes a) -> () val merge: [a] (set a, consumes set a) -> () Then, error in concurrent code: let s = make() in produces set t data race cannot do merge(s, s); cannot do merge(s1, s2); insert(s2, x); cannot do insert(s, x1) and insert(s, x2) in independent threads 4 / 42

21 Permissions, in a nutshell Like a program logic, Mezzo's static discipline is flow-sensitive A current (set of) permission(s) exists at each program point Different permissions exist at different points There is no such thing as the type of a variable A permission has layout and ownership readings A permission is either duplicable or affine 5 / 42

22 What this talk is not about The paper and talk do not discuss: algebraic data types, which describe tree-shaped data, (static) regions, which can describe non-tree-shaped data, adoption & abandon, a dynamic alternative to regions, and much more (ICFP 2013) 6 / 42

23 Algebraic data types data list a = Nil Cons { head: a; tail: list a } data mutable mlist a = MNil Censored MCons { head: a; tail: mlist a } 7 / 42

24 Melding mutable lists val rec meld_aux [a] (xs: MCons { head: a; tail: mlist a }, consumes ys: mlist a) : () = match xstail with MNil -> xstail <- ys MCons -> end Censored meld_aux (xstail, ys) 8 / 42

25 Concatenating immutable lists val rec append_aux [a] (consumes ( dst: MCons { head: a; tail: () }, xs: list a, ys: list a )) : ( list a) = match xs with Cons -> let dst' = MCons { head = xshead; tail = () } in dsttail <- dst'; Nil -> tag of dst <- Cons; append_aux (dst', xstail, ys) dsttail <- ys; tag of dst <- Cons end Censored 9 / 42

26 Regions abstract region val newregion: () -> region abstract rref (rho : value) a fact duplicable (rref rho a) val newrref: (consumes x: a region) -> rref rho a val get: (r: rref rho a duplicable a region) -> a Censored val set: (r: rref rho a, consumes x: a region) -> () 10 / 42

27 Adoption and abandon val dfs [a] (g: graph a, f: a -> ()) : () = let s = stack::new groots in stack::work (s, fun (n: dynamic graph a * stack dynamic) : () = take n from g; if not nvisited then begin nvisited <- true; ) end; f ncontent; stack::push (nneighbors, s) give n to g Censored 11 / 42

28 What this talk is about So, what are the paper and talk about? extend Mezzo with threads and locks; describe a modular, machine-checked proof of type soundness; data race freedom 12 / 42

29 Outline Threads, data races, and locks (by example) Mezzo's architecture The kernel and its proof (glimpses) Conclusion 13 / 42

30 A data race open thread val r = newref 0 val f ( ref int ) : () = r :=!r + 1 val () = spawn f ; spawn f 14 / 42

31 A data race open thread val r = newref 0 val f ( ref int ) : () = r :=!r + 1 val () = spawn f ; spawn f f requires ref int and gives it back 14 / 42

32 A data race open thread val r = newref 0 val f ( ref int ) : () = r :=!r + 1 val () = spawn f ; spawn f spawn f requires ref int and does NOT give it back 14 / 42

33 A data race open thread val r = newref 0 val f ( ref int ) : () = r :=!r + 1 val () = spawn f ; spawn f TYPE ERROR! (in fact, this code is racy) 14 / 42

34 Introducing synchronization open thread open lock val r = newref 0 val l : lock ref int) = new() val f ( ) : () = acquire l; r :=!r + 1; release l val () = spawn f ; spawn f 15 / 42

35 Introducing synchronization open thread open lock val r = newref 0 val l : lock ref int) = new() val f ( ) : () = acquire l; r :=!r + 1; release l val () = spawn f ; spawn f this consumes ref int the lock now mediates access to it 15 / 42

36 Introducing synchronization open thread open lock val r = newref 0 val l : lock ref int) = new() val f ( ) : () = acquire l; r :=!r + 1; release l val () = spawn f ; spawn f f requires no permission lock () is duplicable 15 / 42

37 Introducing synchronization open thread open lock val r = newref 0 val l : lock ref int) = new() val f ( ) : () = acquire l; r :=!r + 1; release l val () = spawn f ; spawn f acquiring the lock produces ref int 15 / 42

38 Introducing synchronization open thread open lock val r = newref 0 val l : lock ref int) = new() val f ( ) : () = acquire l; r :=!r + 1; release l val () = spawn f ; spawn f ref int allows updating r 15 / 42

39 Introducing synchronization open thread open lock val r = newref 0 val l : lock ref int) = new() val f ( ) : () = acquire l; r :=!r + 1; release l val () = spawn f ; spawn f releasing the lock consumes ref int 15 / 42

40 Introducing synchronization open thread open lock val r = newref 0 val l : lock ref int) = new() val f ( ) : () = acquire l; r :=!r + 1; release l val () = spawn f ; spawn f WELL-TYPED! (yup, this code is race free) 15 / 42

41 Abstracting synchronization (* A second-order function *) val hide : [a, b, s : perm ] ( f : (consumes a s) -> b consumes s ) -> (consumes a) -> b 16 / 42

42 Abstracting synchronization (* A second-order function *) val hide : [a, b, s : perm ] ( f : (consumes a s) -> b consumes s ) -> (consumes a) -> b hide is polymorphic in s eg, ref int 16 / 42

43 Abstracting synchronization (* A second-order function *) val hide : [a, b, s : perm ] ( f : (consumes a s) -> b consumes s ) -> (consumes a) -> b hide takes a function f which has a side effect on s 16 / 42

44 Abstracting synchronization (* A second-order function *) val hide : [a, b, s : perm ] ( f : (consumes a s) -> b consumes s ) -> (consumes a) -> b hide consumes s which becomes owned by the lock 16 / 42

45 Abstracting synchronization (* A second-order function *) val hide : [a, b, s : perm ] ( f : (consumes a s) -> b consumes s ) -> (consumes a) -> b hide produces a new function which has no advertised effect 16 / 42

46 A synchronization pattern open lock val hide [a, b, s : perm] ( f : (consumes a s) -> b consumes s ) : (consumes a) -> b = let l : lock s = new () in fun (consumes x : a) : b = acquire l; let y = f x in release l; y 17 / 42

47 Introducing synchronization, revisited open thread open hide val r = newref 0 val f ( ref int) : () = r :=!r + 1 val f = hide f val () = spawn f; spawn f 18 / 42

48 Introducing synchronization, revisited open thread open hide val r = newref 0 val f ( ref int) : () = r :=!r + 1 val f = hide f val () = spawn f; spawn f ref int 18 / 42

49 Introducing synchronization, revisited open thread open hide val r = newref 0 val f ( ref int) : () = r :=!r + 1 val f = hide f val () = spawn f; spawn f ref int ( ref int) -> () 18 / 42

50 Introducing synchronization, revisited open thread open hide val r = newref 0 val f ( ref int) : () = r :=!r + 1 val f = hide f val () = spawn f; spawn f () -> () 18 / 42

51 Introducing synchronization, revisited open thread open hide val r = newref 0 val f ( ref int) : () = r :=!r + 1 val f = hide f val () = spawn f; spawn f WELL-TYPED! (yup, this code is race free) 18 / 42

52 Outline Threads, data races, and locks (by example) Mezzo's architecture The kernel and its proof (glimpses) Conclusion 19 / 42

53 What is Mezzo? A kernel: a λ-calculus with threads; affine, polymorphic, value-dependent, with type erasure Several extensions: mutable state: references; hidden state: locks; dynamic ownership control: adoption and abandon All machine-checked in Coq (14KLOC) 20 / 42

54 Modularity We wish to prove that well-typed programs: do not go wrong; are data-race free This is trivial - true of all programs - in the kernel calculus! Subject reduction and progress are non-trivial results We set up their proof so that it is robust in the face of extensions 21 / 42

55 Modularity We parameterize the kernel with: a type of machine states s; a type of instrumented states R, or resources; which must form a monotonic separation algebra; a correspondence relation, s R Subject reduction and progress hold for all such parameters 22 / 42

56 Pseudo-Modularity The kernel is not parameterized wrt the extensions We add the extensions, one after another, on top of the kernel So, the Coq code is monolithic Fortunately, each extension is (morally) independent of the others; the key statements do not change with extensions; only new proof cases appear 23 / 42

57 Outline Threads, data races, and locks (by example) Mezzo's architecture The kernel and its proof (glimpses) Conclusion 24 / 42

58 Values and terms A fairly unremarkable untyped λ-calculus with threads κ ::= value term soup (Kinds) v ::= x λxt (Values) t ::= v v ṫ spawn v v (Terms) 25 / 42

59 Operational semantics initial configuration new configuration s / (λxt) v s / [v/x]t s / E[t] s / E[t ] if s / t s / t s / thread (t) s / thread (t ) if s / t s / t s / t 1 t 2 s / t 1 t 2 if s / t 1 s / t 1 s / t 1 t 2 s / t 1 t 2 if s / t 2 s / t 2 s / thread (D[spawn v 1 v 2 ]) s / thread (D[()]) thread (v 1 v 2 ) 26 / 42

60 Operational semantics an abstract notion of machine state initial configuration new configuration s / (λxt) v s / [v/x]t s / E[t] s / E[t ] if s / t s / t s / thread (t) s / thread (t ) if s / t s / t s / t 1 t 2 s / t 1 t 2 if s / t 1 s / t 1 s / t 1 t 2 s / t 1 t 2 if s / t 2 s / t 2 s / thread (D[spawn v 1 v 2 ]) s / thread (D[()]) thread (v 1 v 2 ) 26 / 42

61 Types and permissions κ ::= type perm (Kinds) T, U ::= x =v T T (T P) (Types) x : κt x : κt P, Q ::= x T empty P P (Permissions) x : κp x : κp duplicable θ θ ::= T P 27 / 42

62 The typing judgement A traditional type system uses a list Γ of type assumptions: Γ t : T Mezzo splits it into a list K of kind assumptions and a permission P: K, P t : T This can be read like a Hoare triple: K { P} t { T} 28 / 42

63 The typing judgement A typing judgement about a running program (or thread) depends on a resource R: R, K, P t : T R is the thread's partial, instrumented view of the machine state 29 / 42

64 Resources A resource is: partial: a resource could be, say, a heap fragment; instrumented: a resource could record whether each location is mutable or immutable 30 / 42

65 Resources A resource is: partial: a resource could be, say, a heap fragment; instrumented: a resource could record whether each location is mutable or immutable At this stage, though, resources are abstract What properties must we require of them? 30 / 42

66 Monotonic separation algebra R R 1 R 2 R R 1 R 2 resource eg, an instrumented heap fragment maps every address to, N, X v, or D v conjunction eg, requires separation at mutable addresses requires agreement at immutable addresses duplicable core eg, throws away mutable addresses keeps immutable addresses tolerable interference (rely) eg, allows memory allocation 31 / 42

67 Working with abstract resources Star is commutative and associative R 1 R 2 ok implies R 1 ok R R = R R 1 R 2 = R and R ok imply R 1 = R R R = R implies R = R R R = R R R R 1 ok and R 1 R 2 imply R 2 ok R 1 R 2 implies R 1 R 2 rely preserves splits: R 1 R 2 R R 1 R 2 ok R 1R 2, R 1 R 2 = R R 1 R 1 R 2 R 2 32 / 42

68 A small set of typing rules Singleton R; K; P v : =v Frame R; K; P t : T R; K; P Q t : T Q Function R; K, x : value; P T t : U R; K; (duplicable P) P λxt : T U ForallIntro t is harmless R; K, x : κ; P t : T R; K; x : κp t : x : κt ExistsIntro R; K; P v : [U/x]T R; K; P v : x : κt Cut R 2 ; K; P 1 P 2 t : T R 1 ; K P 1 R 1 R 2 ; K; P 2 t : T ExistsElim R; K, x : κ; P t : T R; K; x : κp t : T SubLeft K P 1 P 2 R; K; P 1 t : T R; K; P 2 t : T SubRight R; K; P t : T 1 K T 1 T 2 R; K; P t : T 2 Application R; K; Q t : T R; K; T U) Q v t : U Spawn R; K; (v T U) (v T) spawn v 1 v 2 : 33 / 42

69 Selected typing rules The kernel typing rules manipulate R abstractly R ; K, x : value; P T t : U R; K; (duplicable P) P λxt : T U R 2 ; K; P 1 P 2 t : T R 1 ; K P 1 R 1 R 2 ; K; P 2 t : T 34 / 42

70 Selected typing rules The kernel typing rules manipulate R abstractly R ; K, x : value; P T t : U R; K; (duplicable P) P λxt : T U cannot capture an arbitrary resource R can capture its duplicable core R R 2 ; K; P 1 P 2 t : T R 1 ; K P 1 R 1 R 2 ; K; P 2 t : T 34 / 42

71 Selected typing rules The kernel typing rules manipulate R abstractly R R 2 ; K; P 1 P 2 t : T ; K, x : value; P T t : U R 1 ; K P 1 R; K; (duplicable P) P λxt : T U R 1 R 2 ; K; P 2 t : T if a typing rule has two premises then R must be split between them 34 / 42

72 Subject reduction Lemma (SR, preliminary form) R 2 R 2 s 1 / t 1 s 2 / t 2 s 1 R 1 R 1 R 1 ; ; empty t 1 : T s 2 R 2 R 2 R 2 ; ; empty t 2 : T R 1 R 2 35 / 42

73 Subject reduction one thread takes a step Lemma (SR, preliminary form) R 2 R 2 s 1 / t 1 s 2 / t 2 s 1 R 1 R 1 R 1 ; ; empty t 1 : T s 2 R 2 R 2 R 2 ; ; empty t 2 : T R 1 R 2 35 / 42

74 Subject reduction Lemma (SR, preliminary form) R 2 R 2 this thread's view is R 1 the other threads' view is R 1 s 1 / t 1 s 2 / t 2 s 1 R 1 R 1 R 1 ; ; empty t 1 : T s 2 R 2 R 2 R 2 ; ; empty t 2 : T R 1 R 2 35 / 42

75 Subject reduction Lemma (SR, preliminary form) R 2 R 2 this thread is well-typed under its view s 1 / t 1 s 2 / t 2 s 1 R 1 R 1 R 1 ; ; empty t 1 : T s 2 R 2 R 2 R 2 ; ; empty t 2 : T R 1 R 2 35 / 42

76 Subject reduction Lemma (SR, preliminary form) R 2 R 2 s 1 / t 1 s 2 / t 2 s 1 R 1 R 1 R 1 ; ; empty t 1 : T s 2 R 2 R 2 R 2 ; ; empty t 2 : T R 1 R 2 this thread's view and the other threads' view evolve 35 / 42

77 Subject reduction Lemma (SR, preliminary form) R 2 R 2 s 1 / t 1 s 2 / t 2 s 1 R 1 R 1 R 1 ; ; empty t 1 : T s 2 R 2 R 2 R 2 ; ; empty t 2 : T R 1 R 2 the new machine state agrees with the new views 35 / 42

78 Subject reduction Lemma (SR, preliminary form) R 2 R 2 s 1 / t 1 s 2 / t 2 s 1 R 1 R 1 R 1 ; ; empty t 1 : T s 2 R 2 R 2 R 2 ; ; empty t 2 : T R 1 R 2 the thread remains well-typed under its view 35 / 42

79 Subject reduction Lemma (SR, preliminary form) R 2 R 2 s 1 / t 1 s 2 / t 2 s 1 R 1 R 1 R 1 ; ; empty t 1 : T s 2 R 2 R 2 R 2 ; ; empty t 2 : T R 1 R 2 the interference inflicted on the other threads is tolerable 35 / 42

80 Subject reduction Theorem (Subject Reduction) Reduction preserves well-typedness c 1 c 2 c 1 c 2 36 / 42

81 Progress A configuration c is acceptable if every thread: has reached an answer; or is able to make one step; or (after introducing locks) is waiting on a locked lock Theorem (Progress) Every well-typed configuration is acceptable 37 / 42

82 Data race freedom Cannot be stated for the kernel We introduce references first There, writing requires an exclusive access right Hence, it is easy to prove that: Theorem A well-typed program cannot exhibit a data race 38 / 42

83 Outline Threads, data races, and locks (by example) Mezzo's architecture The kernel and its proof (glimpses) Conclusion 39 / 42

84 Related work Alias Types Separation Logic L 3 (And a lot more) Views (Dinsdale-Young et al, 2013) are particularly relevant extensible framework; monolithic machine state, composable views, agreement; while-language instead of a λ-calculus 40 / 42

85 A few lessons The good old syntactic approach to type soundness works Formalization helps clarify and simplify A lot In the end, it is just affine λ-calculus 41 / 42

86 Thank you More information in the paper and online: Try it out! 42 / 42

87 Road map weakening affinity duplication substitution stability classification decomposition type soundness subject reduction progress soundness of subsumption canonicalization 1 / 7

88 Dealing with binding In Coq, we use only one syntactic category Well-kindedness distinguishes values, terms, types, etc avoids a quadratic number of substitution functions! makes it easy to deal with dependency Binding encoded via de Bruijn indices Re-usable library, dblib The main hygiene lemmas have >90 cases and 4-line proofs 2 / 7

89 Algebraic data types data list a = Nil Cons { head: a; tail: list a } data mutable mlist a = MNil MCons { head: a; tail: mlist a } 3 / 7

90 Melding mutable lists val rec meld_aux [a] (xs: MCons { head: a; tail: mlist a }, consumes ys: mlist a) : () = match xstail with MNil -> xstail <- ys MCons -> meld_aux (xstail, ys) end 4 / 7

91 Concatenating immutable lists val rec append_aux [a] (consumes ( dst: MCons { head: a; tail: () }, xs: list a, ys: list a )) : ( list a) = match xs with Cons -> let dst' = MCons { head = xshead; tail = () } in dsttail <- dst'; tag of dst <- Cons; append_aux (dst', xstail, ys) Nil -> dsttail <- ys; tag of dst <- Cons end 5 / 7

92 Regions abstract region val newregion: () -> region abstract rref (rho : value) a fact duplicable (rref rho a) val newrref: (consumes x: a region) -> rref rho a val get: (r: rref rho a duplicable a region) -> a val set: (r: rref rho a, consumes x: a region) -> () 6 / 7

93 Adoption and abandon val dfs [a] (g: graph a, f: a -> ()) : () = let s = stack::new groots in stack::work (s, fun (n: dynamic graph a * stack dynamic) : () = take n from g; if not nvisited then begin nvisited <- true; f ncontent; stack::push (nneighbors, s) end; give n to g ) 7 / 7

The theory of Mezzo. François Pottier. IHP, April 2014 INRIA

The theory of Mezzo. François Pottier. IHP, April 2014 INRIA The theory of Mezzo François Pottier INRIA IHP, April 2014 1 / 94 Acknowledgements Jonathan Protzenko, Thibaut Balabonski, Henri Chataing, Armaël Guéneau, Cyprien Mangin. 2 / 94 Outline Introduction The