shared session types for safe, practical concurrencybalzers/publications/safe_concurrency.pdf ·...

Shared Session Types for Safe, Practical Concurrency1

Stephanie Balzer Carnegie Mellon University

Typelevel Summit Philadelphia 2019

1 Supported by a Mozilla Research Grant and NSF Grant No. CCF-1718267

Concurrency is ubiquitous

�2


The world surrounding us is inherently concurrent

�2


�3



Many programming problems demand concurrency • Flight booking system, online store, search engines, etc.

�3




Computing devices themselves are concurrent • Run various apps concurrently

�3





�3

programming languages must support concurrency





�3

programming languages must support concurrency

concurrent programming is notoriously difficult and error-prone


Two models for concurrent programming

�4


�4

Legend: concurrently executing component

shared dataread/write

Shared memory


�4



Shared memory

message

Message-passing


�4



Shared memory

message

Message-passing

• computation by reading fromand writing to shared data


�4



Shared memory

message

Message-passing


• computation by exchangeof messages


�4



Shared memory

message

Message-passing



message-passing offers higher-level of abstraction


�4



Shared memory

message

Message-passing



message-passing offers higher-level of abstraction

message-passing adopted by practical languages such as Erlang, Go, and Rust.

My research

�5

My research

�5

Goal: make concurrent programming safe and practical

My research

�5


message-passing model

session types to express protocols of message exchange and reason sequentially about communicating parties

My research

�5



Contributions:


My research

�5



Contributions:shared session types


My research

�5



Contributions:shared session types

accommodate real-world programming scenarios

guarantee protocol adherence, data-race-freedom, and deadlock-freedom


Session types, what are they? Why do we need them in practice?

�6

Message-passing concurrency in Servo

�7


• Servo is Mozilla’s next-generation browser engine under development and implemented in Rust.

• Servo uses message-passing concurrency for maximal parallelization of tasks, such as loading and rendering of webpage elements.

�7




�7

Image loader:




�7

ImageCache

Image loader:




�7

ImageCache Client

CmdReceiver

Legend: channelcomponent, runs in separate thread

Image loader:




�7

ResourceThread ImageCache Client

CmdReceiver


Image loader:




�7


CmdReceiver

Decoder1 Decodern


Image loader:




�7


CmdReceiver

Decoder1 Decodern


request

Image loader:




�8


CmdReceiver

Decoder1 Decodern


Image loader:




�8


CmdReceiver

Decoder1 Decodern


exit

Image loader:




�9


CmdReceiver

Decoder1 Decodern


Image loader:




�9


CmdReceiver

Decoder1 Decodern


kill

Image loader:


�10


CmdReceiver

Decoder1 Decodern


Image loader:


�10


CmdReceiver

Decoder1 Decodern


To restrict the kinds of messages that can be sent over a channel, Rust channels are typed with enumeration types.

Image loader:


�10


CmdReceiver

Decoder1 Decodern


To restrict the kinds of messages that can be sent over a channel, Rust channels are typed with enumeration types.

Image loader:

Example: enumeration for ImageCache


�11


CmdReceiver

Decoder1 Decodern


Image loader:


�11


CmdReceiver

Decoder1 Decodern


pub enum ImageCacheCommand { RequestImage (Url, ImageCacheChan, Option<ImageResponder>), GetImageIfAvailable (Url, UsePlaceholder, IpcSender<Result<Arc<Image>, ImageState>>), StoreDecodeImage (Url, Vec<u8>), … // Clients must wait for a response before shutting down ResourceThread Exit () }

Image loader:


�11


CmdReceiver

Decoder1 Decodern



one variant for each message

Image loader:


�12


CmdReceiver

Decoder1 Decodern



Image loader:


�12


CmdReceiver

Decoder1 Decodern



implicit protocolImage loader:


�12


CmdReceiver

Decoder1 Decodern



implicit protocolImage loader:

protocol breaches result in proliferation of panic! and

infinite waiting


�13


implicit protocol


infinite waiting


�13


implicit protocol

enumeration types ensure that only defined messages can be communicated along a channel


infinite waiting


�13


implicit protocol


enumeration types fail to ensure that messages are sent according to the intended protocol


infinite waiting


�13


implicit protocol


enumeration types fail to ensure that messages are sent according to the intended protocol

let’s use session types!


infinite waiting

Session types

�14

Session types

�14

Session types define protocols of message exchange.

Session types

�14


“protocol = sequence of actions”

Session types

�14



A,B , N{li : Ai} external choice

�{li : Ai} internal choice

A ( B channel input

A⌦B channel output

1 termination

T ! A value input

T ⇥A value output

T , int | string | . . .

Session types

�14





A ( B channel input


1 termination

T ! A value input

T ⇥A value output


client chooses among sending

one of the labels li

Session types

�15





A ( B channel input


1 termination

T ! A value input

T ⇥A value output


Session types

�15





A ( B channel input


1 termination

T ! A value input

T ⇥A value output


provider chooses among sending

one of the labels li

Session types

�16





A ( B channel input


1 termination

T ! A value input

T ⇥A value output


Session types

�16





A ( B channel input


1 termination

T ! A value input

T ⇥A value output


client sends channel reference of

type A

Session types

�17





A ( B channel input


1 termination

T ! A value input

T ⇥A value output


Session types

�17





A ( B channel input


1 termination

T ! A value input

T ⇥A value output


provider sends channel reference of

type A

Session types

�18





A ( B channel input


1 termination

T ! A value input

T ⇥A value output


Session types

�18





A ( B channel input


1 termination

T ! A value input

T ⇥A value output

T , int | string | . . .provider terminates

Session types

�18





A ( B channel input


1 termination

T ! A value input

T ⇥A value output


Session types

�19





A ( B channel input


1 termination

T ! A value input

T ⇥A value output


Session types

�19





A ( B channel input


1 termination

T ! A value input

T ⇥A value output


support communication of

values

Session type for image loader

�20



A ( B channel input


1 termination

T ! A value input

T ⇥A value output



�20



A ( B channel input


1 termination

T ! A value input

T ⇥A value output


ImgCacheCmd = N {RequestImage : string ! Requester ( ImgCacheCmd,. . .Exit : � {Running : ImgCacheCmd,

Done : ResourceThread⌦ 1}}


�21



A ( B channel input


1 termination

T ! A value input

T ⇥A value output





�22



A ( B channel input


1 termination

T ! A value input

T ⇥A value output





�23



A ( B channel input


1 termination

T ! A value input

T ⇥A value output





�24



A ( B channel input


1 termination

T ! A value input

T ⇥A value output





�25




�25




CmdReceiver

Decoder1 Decodern


�25



ImageCache:


CmdReceiver

Decoder1 Decodern


�25



ImageCache:


CmdReceiver

Decoder1 Decodern

ImgCacheCmd


�25



ImageCache:


CmdReceiver

Decoder1 Decodern

RequestImage

ImgCacheCmd


�26



ImageCache:


CmdReceiver

Decoder1 Decodern


�26



ImageCache:


CmdReceiver

Decoder1 Decodern

string ! Requester ( ImgCacheCmd


�26



ImageCache:


CmdReceiver

Decoder1 Decodern

“http://…”



�27



ImageCache:


CmdReceiver

Decoder1 Decodern

Requester ( ImgCacheCmd


�27



ImageCache:


CmdReceiver

Decoder1 Decodern

c

Requester ( ImgCacheCmd


�28



ImageCache:


CmdReceiver

Decoder1 Decodern

ImgCacheCmd


�28



ImageCache:


CmdReceiver

Decoder1 Decodern

Exit

ImgCacheCmd


�29



ImageCache:


CmdReceiver

Decoder1 Decodern

�{Running : ImgCacheCmd,Done : ResourceThread⌦ 1}


�29



ImageCache:


CmdReceiver

Decoder1 Decodern

Running

�{Running : ImgCacheCmd,Done : ResourceThread⌦ 1}


�30



ImageCache:


CmdReceiver

Decoder1 Decodern

ImgCacheCmd


�30

ImageCache:


CmdReceiver

Decoder1 Decodern

ImgCacheCmd


�31

ImageCache:


CmdReceiver

Decoder1 Decodern

ImgCacheCmd

components change their session type along with message exchange

Taking stock

�32

Taking stock

• Session types make explicit the protocols of message exchange between concurrently executing components.

�32

Taking stock


• Typing ensures protocol adherence.

�32

Taking stock



• Types make explicit interdependencies between components, enabling sequential reasoning about a component.

�32

Taking stock



• Types make explicit interdependencies between components, enabling sequential reasoning about a component.

�32

Session types are the types of message-passing concurrency.

Session types in research and practice

�33


Research • active research area since inception in 90s [Honda 1993] • logical reconstruction based on linear logic, providing strong

guarantees [Caires & Pfenning 2010, Wadler 2012] • extension of logical session types to sharing [Balzer & Pfenning ICFP

2017, Balzer et al. CONCUR 2018, Balzer et al. ESOP 2019]

�33


Research • active research area since inception in 90s [Honda 1993] • logical reconstruction based on linear logic, providing strong

guarantees [Caires & Pfenning 2010, Wadler 2012] • extension of logical session types to sharing [Balzer & Pfenning ICFP

2017, Balzer et al. CONCUR 2018, Balzer et al. ESOP 2019]

Practice • Lightweight integration of session types or session libraries (with

varying static guarantees) into Scala, Java, Haskell, OCaml, Go, Rust, Python.

• Collaboration with Mozilla Research on integrating our work.

�33

Logic-based shared session types

�34

Linear logic session types

�35


Provide strong guarantees: • Data-race-freedom • Protocol adherence (a.k.a. session fidelity, preservation) • Deadlock-freedom (a.k.a. progress)

�35



�35

exactly one client



�35

exactly one client

processes graph forms a tree at run-time


Provide strong guarantees • Data-race-freedom • Protocol adherence (a.k.a. session fidelity, preservation) • Deadlock-freedom (a.k.a. progress)

But, they rule out sharing

�36




�36


CmdReceiver

Decoder1 Decodern




�36


CmdReceiver

Decoder1 Decodern

both CmdReceiver and Client communicate with

ImageCache




�37

Linear logic session types cannot accommodate certain practical programming scenarios.




�37

Let’s introduce sharing while maintaining above guarantees.

Linear logic session types cannot accommodate certain practical programming scenarios.

Challenges of sharing

�38


�38




CmdReceiver

Decoder1 Decodern


�38



ImageCache:


CmdReceiver

Decoder1 Decodern

ImgCacheCmd


�38



ImageCache:


CmdReceiver

Decoder1 Decodern

RequestImage

ImgCacheCmd


�39



ImageCache:


CmdReceiver

Decoder1 Decodern



�39



ImageCache:


CmdReceiver

Decoder1 Decodern

Exit


protocol violated!


�40




CmdReceiver

Decoder1 Decodern

How to restore protocol adherence in the presence of sharing (a.k.a. aliasing)?

Idea: acquire-release

�41


�41

Clients of shared channels must communicate along that channel in mutual exclusion from each other.


�41


Acquiring a shared channel gives exclusive access, releasing an acquired channel relinquishes exclusive access.


�41




CmdReceiver

Decoder1 Decodern


�42




CmdReceiver

Decoder1 Decodern

Legend: shared channel


�42




CmdReceiver

Decoder1 Decodern

Legend: shared channel

acquire


�43




CmdReceiver

Decoder1 Decodern

Legend: shared channel linear channel


�43




CmdReceiver

Decoder1 Decodern


critical section


�43




CmdReceiver

Decoder1 Decodern

release


critical section


�44




CmdReceiver

Decoder1 Decodern


Have we restored protocol adherence?

�45


�45


CmdReceiver

Decoder1 Decodern


ImgCacheCmd = N{RequestImage : string ! Requester ( ImgCacheCmd,Exit : � {Running : ImgCacheCmd,



�45


CmdReceiver

Decoder1 Decodern


ImageCache: ImgCacheCmd




�45


CmdReceiver

Decoder1 Decodern


acquire





�46


CmdReceiver

Decoder1 Decodern






�46


CmdReceiver

Decoder1 Decodern





RequestImage


�47


CmdReceiver

Decoder1 Decodern


ImageCache:





�47


CmdReceiver

Decoder1 Decodern


ImageCache:



release



�48


CmdReceiver

Decoder1 Decodern


ImageCache:





�48


CmdReceiver

Decoder1 Decodern


ImageCache:




acquire


�49


CmdReceiver

Decoder1 Decodern


ImageCache:





�49


CmdReceiver

Decoder1 Decodern


ImageCache:




Exit

protocol violated!

Idea: equi-synchronizing

�50


�50

In addition to imposing acquire-release on shared channels, shared channels must be equi-synchronizing:


�50

i.e., shared channels must be released back to the same type at which they were acquired, if released.



�50



ImgCacheCmd = N{RequestImage : string ! Requester ( ImgCacheCmd,Exit : � {Done : ResourceThread⌦ 1,

Running : ImgCacheCmd}}


�50



acquire




�50



acquire



release


�50



acquire



release✓


�50



acquire



release

release

✓


�50



acquire



release

release

✓

✓


�50



acquire



release

release

release ✓

✓


�50



acquire



release

release

release ✓✗

✓

Taking stock

�51

Taking stock

�51

Acquire-release + equi-synchronizing:

Taking stock

�51


restore protocol adherence;

Taking stock

�51



guarantee freedom of (high-level) data races because execution between acquire-release is atomic.

Taking stock

�51




We could state the policy of acquire-release and equi-synchronizing as a programming methodology.

Taking stock

�51




We could state the policy of acquire-release and equi-synchronizing as a programming methodology.

But, why not lift this policy to the type level and have it enforced statically?

Manifest sharing

�52

Manifest sharing

�52

acquire



release

release

Manifest sharing

�52

acquire



release

release

Legend: shared phase linear phase

Manifest sharing

�53

Manifest sharing

�53

Stratify session types into a linear and shared layer

Manifest sharing

�53

AS � ↑SLAL

AL,BL � ⊕{l ∶ AL} � AL ⊗BL � 1 � ∃x∶AS.BL �N{l ∶ AL} � AL � BL � ↓SLAS � ⇧x∶AS.BL


Manifest sharing

�53

AS � ↑SLAL



Connect layers with modalities going back and forth

Manifest sharing

�53

AS � ↑SLAL



Connect layers with modalities going back and forth

Support communication of shared channels

Manifest sharing

�54

AS � ↑SLAL


Manifest sharing

�54

AS � ↑SLAL


ImgCacheCmd = "S

L N{RequestImage : string ! Requester ( #S

L ImgCacheCmd,

Exit : � {Done : ResourceThread⌦ 1,

Running : #S

L ImgCacheCmd}}

Manifest sharing

�54

AS � ↑SLAL


Up and down shifts denote acquire and release, resp.

ImgCacheCmd = "S

L N{RequestImage : string ! Requester ( #S

L ImgCacheCmd,

Exit : � {Done : ResourceThread⌦ 1,

Running : #S

L ImgCacheCmd}}

Typing judgments

�55

AS � ↑SLAL


Typing judgments

�55

AS � ↑SLAL


Based on correspondence between intuitionistic linear logic and session-typed pi-calculus:

Typing judgments

�55

�; � �⌃ P ∶∶ (xL ∶ AL)� �⌃ P ∶∶ (xS ∶ AS)

AS � ↑SLAL



Typing judgments

�55

�; � �⌃ P ∶∶ (xL ∶ AL)� �⌃ P ∶∶ (xS ∶ AS)

AS � ↑SLAL



“Process P provides session of type Am along xm using channels in (� and) �.”

Typing judgments

�55

�; � �⌃ P ∶∶ (xL ∶ AL)� �⌃ P ∶∶ (xS ∶ AS)

AS � ↑SLAL




shared (structural) context

Typing judgments

�56

�; � �⌃ P ∶∶ (xL ∶ AL)� �⌃ P ∶∶ (xS ∶ AS)

AS � ↑SLAL




Typing judgments

�56

�; � �⌃ P ∶∶ (xL ∶ AL)� �⌃ P ∶∶ (xS ∶ AS)

AS � ↑SLAL




linear (substructural) context

Typing of acquire

�57

Typing of acquire

�57

�, xS ∶↑SL AL; �, xL ∶ AL �⌃ QxL ∶∶ (zL ∶ CL)�, xS ∶↑SL AL; � �⌃ xL ← acquire xS ;QxL ∶∶ (zL ∶ CL) (T-↑SLL)

Typing of acquire

�57

�, xS ∶↑SL AL; �, xL ∶ AL �⌃ QxL ∶∶ (zL ∶ CL)�, xS ∶↑SL AL; � �⌃ xL ← acquire xS ;QxL ∶∶ (zL ∶ CL) (T-↑SLL)

�; ⋅ �⌃ PxL ∶∶ (xL ∶ AL)� �⌃ xL ← accept xS ;PxL ∶∶ (xS ∶↑SL AL) (T-↑SLR)

Typing of release

�58

Typing of release

�58

�, xS ∶ AS; � �⌃ QxS ∶∶ (zL ∶ CL)�; �, xL ∶↓SL AS �⌃ xS ← release xL ;QxS ∶∶ (zL ∶ CL) (T-↓SLL)

Typing of release

�58

�, xS ∶ AS; � �⌃ QxS ∶∶ (zL ∶ CL)�; �, xL ∶↓SL AS �⌃ xS ← release xL ;QxS ∶∶ (zL ∶ CL) (T-↓SLL)

� �⌃ PxS ∶∶ (xS ∶ AS)�; ⋅ �⌃ xS ← detach xL ;PxS ∶∶ (xL ∶↓SL AS) (T-↓SLR)

Taking stock

�59

Taking stock

�59

We have a session type system that allows shared and linear channels to coexist and guarantees:

data-race-freedom (low-level and high-level)

protocol adherence

Taking stock

�59



protocol adherence

What about deadlock-freedom?

Why are linear session types deadlock-free?

�60


�60

Linearity (“exactly one client”) turns process graph into a tree.


�60

a

b c d

e f g

parent: client

child: provider


Legend: linear channel


�61

a

b c d

e f g




What are the threats to progress?

�61

a

b c d

e f g




What are the threats to progress?• Two scenarios:

�61

a

b c d

e f g





• provider ready to synchronize, client not

�61

a

b c d

e f g





• provider ready to synchronize, client not• client ready to synchronize, provider not

�61

a

b c d

e f g






• Let’s visualize this waiting dependency with a green arrow

�61

a

b c d

e f g







�61

a

b c d

e f g

Legend: linear channel a b “a waits for b”






�61

a

b c d

e f g

Legend: linear channel a b “a waits for b”

No green cycles: green arrows can only go along linear channels, and client and provider cannot both be waiting for each other.


Let’s add sharing

�62

Let’s add sharing

�62

We get a graph of linear and shared processes, with a linear tree inside.

Let’s add sharing

�62

a

b c d

e f g


Legend: linear channel linear process

shared channel

shared process

Let’s add sharing

�63

a

b c d

e f g



shared channel

shared process

Let’s add sharing

�63

a

b c d

e f g



shared channel

shared process

Acquire-release amounts to “locking”

Let’s add sharing

�63

a

b c d

e f g



shared channel

shared process

Acquire-release amounts to “locking”• Possibility of cyclic dependencies

Let’s add sharing

�63

a

b c d

e f g



shared channel

shared process

Acquire-release amounts to “locking”• Possibility of cyclic dependencies• Let’s visualize this waiting dependency

with a red arrow

Let’s add sharing

�63

a

b c d

e f g



shared channel

shared process


with a red arrow

a b “a waits for b to release resource”

Let’s add sharing

�63

a

b c d

e f g



shared channel

shared process


with a red arrow• Note: red arrows can connect arbitrary

nodes

a b “a waits for b to release resource”

Can we re-establish deadlock-freedom?

�64


An enticing solution: “locking up” • Impose a partial order on resources. • Ensure that resources are acquired (“locked”) in increasing order.

�64



�64

However, cyclic dependencies between acquire requests are not the only source of deadlock!



�64


Two Forms of waiting dependencies:



�64


Two Forms of waiting dependencies:• waiting to synchronize: a b “a waits for b to synchronize”



�64


Two Forms of waiting dependencies:• waiting to synchronize:• waiting to release:

a b “a waits for b to synchronize”a b “a waits for b to release resource”


�65

Two Forms of waiting dependencies: • waiting to synchronize: • waiting to release:



�65



a

b c d

e f g


�65



a

b c d

e f g

a

b d d

e f g


�65



a

b c d

e f g

a

b d d

e f g

Cycles can consist of red arrows only or a combination of red and green arrows.

Idea: competitors and collaborators

�66


�66

Competitors: overlap in set of resources acquired


�66


Collaborators: do not overlap in set of resources acquired


�66

Notice: a resource acquired becomes a child of the acquirer




�66

a


b c

12




�67

a


b c

1

2




�68

a


b c

1 2




�69

a


b c

1 2



competitors tend to be siblings


�69

a


b c

1 2




{b, c}


�69

a


b c

1 2



collaborators tend to be in the same branch


{b, c}


�69

a


b c

1 2



collaborators tend to be in the same branch


{a, b, 1} {a, b, 2} {a, c}

{b, c}

Manifest deadlock-freedom

�70


�70

Define type system enforcing the following invariants:

collaborators

a

b c

1 2

competitors


�70


collaborators

a

b c

1 2

competitors

competitors employ locking-up for resources they compete forA


�70


collaborators

a

b c

1 2

competitors

collaborators acquire mutually disjoint sets of resourcesB



�70


collaborators

a

b c

1 2

competitors



competitors have released all acquired resources when synchronizing with other competitors (“tallking-up”)

C


�70


collaborators

a

b c

1 2

competitors



competitors have released all acquired resources when synchronizing with other competitors (“tallking-up”)

C

A rules out red-arrow cycles, B and C rule out red-green-arrow cycles.


�71


�71

Introduce a world, an abstract value equipped with a partial order.


�71

Every process invariantly resides at a world.



�71


Every process indicates the range of worlds it may acquire.



�71




; � `⌃ P :: (xS : AS[!kl!n!l

]) (where + irreflexive)

; �; �; � `⌃ P :: (xL : AL[!kl!n!l



�71




; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l


worlds associated with process


�72




; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l



�72




; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l


self-world: world at which process

resides


�73




; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l



�73




; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l


min-world: world of minimal resource

to be acquired


�74




; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l



�74




; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l


max-world: world of maximal resource to be

acquired


�75




; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l



�75




; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l


world order


�76




; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l



�76




; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l


possibly “aliased” linear channels


�77

; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l



�77

; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l


Express invariants A, B, and C in terms of:


�77

; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l



min(parent) ≤ self(acquired_child) ≤ max(parent)


�77

; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l




max(parent) < min(child)


�77

; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l





collaborators

a

b c

1 2

competitors

no vertical red arrows


�78

; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l






�78

; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l





for an acquire: lock-up


�78

; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l






collaborators

a

b c

1 2

competitors

no red cycles


�79

; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l







�79

; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l






for right-rule: Φ must be empty


�79

; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l







collaborators

a

b c

1 2

competitors

no ingoing red and up-going green arrow


�80

; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l








�80

; � `⌃ P :: (xS : AS[!kl!n!l


; �; �; � `⌃ P :: (xL : AL[!kl!n!l







These low-level invariants are enforced by typing.

Taking stock

�81

Taking stock

�81



protocol adherence

deadlock-freedom

Taking stock

�81



protocol adherence

deadlock-freedom

We have increased practicality of linear session types while maintaining their guarantees.

Current & future work

�82

Digital contracts (with Hoffmann, Pfenning, and Das)

�83


�83

Unique application field for shared session types:


�83


auction = "S

L � {running : N{bid : id ! money ( #S

Lauction,cancel : #S

Lauction},ended : id ! �{won : lot⌦ #S

Lauction,lost : money ⌦ #S

Lauction}}


�83


auction = "S





Lauction}}

Resource analysis for static prediction of execution cost.


�83


auction = "S





Lauction}}

Resource analysis for static prediction of execution cost.

Under development: Nomos, a digital contract language based on resource-aware shared session types.

Unifying parallelism and concurrency

�84


�84

Shared session types recover expressiveness of untyped asynchronous pi-calculus [Balzer et al. CONCUR 2018]


�84


introduce nondeterminism


�84



linear logic session types are deterministic


�84



linear logic session types are deterministic

Opportunity for unifying framework that combines both deterministic (parallel) and nondeterministic (concurrent) computation.

Thank you for your attention!

Papers for this talk: • Stephanie Balzer and Frank Pfenning: Manifest Sharing with Session

Types. ICFP 2017. • Stephanie Balzer, Bernardo Toninho, and Frank Pfenning: Manifest

Deadlock-Freedom for Shared Session Types. ESOP 2019. • Stephanie Balzer, Frank Pfenning, and Bernardo Toninho: A Universal

Session Type for Untyped Asynchronous Communication. CONCUR 2019.

�85

shared session types for safe, practical concurrencybalzers/publications/safe_concurrency.pdf ·...

Documents