ALIASING CONTROL WITH VIEWBASED TYPESTATE Filipe Milito 1
ALIASING CONTROL WITH VIEW-BASED TYPESTATE Filipe Militão 1, 2 Jonathan Aldrich 1 Luís Caires 2 1 Carnegie Mellon University Pittsburgh, USA 2 CITI / Dep. Informática FCT-UNL, Portugal FTf. JP 2010 – Maribor, Slovenia (June 22 nd 2010)
What is an object protocol ? Type-check Object-Oriented Languages Some objects define protocols : clients are required to obey specific sequences in calls to that object Example: File call close after open, not before. Goal: check protocol correctness statically 2
TYPESTATE tracks protocols TYPES to reason about STATE File example ( PLAID–like syntax: explicit states ): receiver pre-state none open()[ receiver post-state File >> Open. File ] { … } none close()[ Open. File >> Closed. File ] { … } File open() Open File 3 close() Closed File
The aliasing problem How to handle state transitions if there aliases? none open. These(File>>Open. File a, File>>Open. File b)[…]{ a. open(); b. open(); } File What if a and b point to the same object? How to express aliasing information? 4 File
Aliasing descriptors aliasing descriptors – fixed number of tags Example (access permissions): unique full * pure unique File full File * pure File Each permission puts methods into separate sets Are these permissions enough? More sets? Do we always need that many? Always meaningful? Are they too complex to use? 5
Introducing VIEWS Each VIEW is: a portion/partition of the full object unique (with only one single owner/alias) checked separately of other views VIEWS are small chunks of an object view 6 client
Beyond unique VIEWS Allow unbounded sharing of (replicable) VIEWS: single owner read + write multiple owners read track sharing using fractions [Boyland 2003] 1/4 1/2 R+W R R R 1/4 1 7 1/2 R collecting all restores write access
Goals of this work Merge STATE and ALIASING CONTROL in a single abstraction: VIEWS More generic ( …beyond aliasing descriptors ) Improved clarity ( more tightly modeling the designer’s intent ) More fine grained permission control Type system Type based verification of correct use of object protocols using views 8
Pair Example A Pair is a group of two elements: Left & Right 9
Pair Initialization NOT INITIALIZED EMPTY E/MPTY EMPTY Splits Merges LEFTPAIR RIGHT (symmetric) set. Left Transitions (asymmetric) LEFT PAIR set. Right RIGHT INITIALIZED 10
Syntax new Empty. Pair() • contains union of all view fields • initially set to null empty type: none class Empty. Pair { /* view declarations */ view Empty. Left { none l; } view Empty. Right { none r; } view Pair { L l; RVr; IEW } DECLARATIONS view Right { R r; } view Left { L l; } accessible fields (private) CLASS CODE /* view equations */ Empty. Pair = Empty. Left Empty. Right VIEW E*QUATIONS Pair = Left * Right } checked for consistency equations (public) /* methods */ none set. Left(L>>none x)[Empty. Left>>Left]{ this. l = x; METHOD DECLARATIONS } x taken by the method body! //. . . 11
Transitions No access to this none auto_init(Empty. Left>>Left l, Empty. Right>>Right r) [none>>none]{ l : Empty. Left r : Empty. Right l : Left r : Right l. set. Left( new L() ); r. set. Right( new R() ); } 12
Splitting & Merging //view equations Empty. Pair = Empty. Left * Empty. Right Pair = Left * Right none init()[Empty. Pair >> Pair] { this : Empty. Pair this : none * Empty. Left * Empty. Right this. auto_init(this, this); borrows each view this : : none Pair * Left * Right } 13
Problem: Pack / Unpack this. r: R none method()[Pair>>Pair]{ this: Pair this. destroy. X(this. r); } illegal call! x would be a partial alias of this! none destroy. X(R>>none x)[Pair>>Pair]{ … } Disallow simultaneous access to this and its fields this XOR FIELDS 14
Pack / Unpack none pair-method()[Pair>>Pair]{ none inspect. R(R>>R x)[Left>>Left] { … } this. inspect. R(this. r); } only requires Left and not Pair legal call! this: Left * Right this: Pair Unpack 15 this. r: R
Lamp Example Unique owner to modify the state of the Lamp Unbounded reading of its light intensity value 16
Lamp class Lamp. Off { const – immutable, safe to duplicate view Lamp. On { Integer bulb; } view Static. Lamp { const Integer bulb; } Lamp. On = Static. Lamp! //… } Replicable! Single Writer XOR Multiple Readers Lamp. On = Static. Lamp! READ + WRITE READ ONLY fullpartial (1) (1/2) Static. Lamp 17 All collected, full fraction
Fractions N!N/ * N// 18
Lamp class Lamp. Off { view Lamp. On { Integer bulb; } view Static. Lamp { const Integer bulb; } Lamp. On = Static. Lamp! none turn. On() [ Lamp. Off >> Lamp. On ] { … } none turn. Off()[ Lamp. On >> Lamp. Off ] { … } Integer get. Light. Intensity() [ Static. Lamp? >> Static. Lamp? ] { bulb } } works with any generic fraction (both full and partial) 19
Cell Example Cell containing one Lamp 20
Cell class Empty. Cell { field type must also be replicable (!) view Read. Only { const Static. Lamp! lamp; } view Filled. Cell. Off { Lamp. Off lamp; } view Filled. Cell. On { Lamp. On lamp; } Filled. Cell. On = Read. Only! Integer read. Intensity()[Read. Only? >> Read. Only? ] { … } //… } 21
Type System 22
Call ( ? Instantiation ) none m 1(Read. Only! >> Read. Only! x ) [none >> none]{ x: x: Read. Only! Read. Only/ * Read. Only/ x: Read. Only/ * Read. Only// /? Read. Only /? none n( Read. Only >> a, //? ? Read. Only // >> b, //? Read. Only //? >> Read. Only c )[none>>none] { … } this. n(x, x, x); } x: Read. Only/ * Read. Only// x: Read. Only/ Read. Only! * Read. Only// 23
Pack / Unpack none cell-method()[Read. Only!>>Read. Only!]{ this: Read. Only! * Read. Only/ this: Read. Only/ view Read. Only { const Static. Lamp! lamp; } this: Read. Only/ this. lampconst: Static. Lamp/ none check. Lamp( Static. Lamp? >> Static. Lamp? x) [ Read. Only? >> Read. Only? ] { … } this. check. Lamp(this. lamp); } 24
Related Work Bierhoff & Aldrich, MODULAR TYPESTATE CHECKING OF ALIASED OBJECTS (2007). Caires, SPATIAL-BEHAVIORAL TYPES FOR CONCURRENCY AND RESOURCE CONTROL IN DISTRIBUTED SYSTEMS (2008). Qi & Myers, MASKED TYPES FOR SOUND OBJECT INITIALIZATION (2009). Leino, DATA GROUPS: SPECIFYING THE MODIFICATION OF EXTENDED STATE (1998). 25
Future Work: coordination coordinator Empty SINGLE CELL Full READER SHARED BUFFER 26 WRITER
Future Work: coordination FULL? I can read! coordinator EMPTY? I can write! Empty Full READER SHARED BUFFER 27 WRITER
Summary VIEWS - new abstraction merges state and aliasing multiple readers single writer readers counted using fractions brief introduction of the type system more details in the paper: Filipe Militão , Jonathan Aldrich , Luís Caires Aliasing control with view-based typestate 28
- Slides: 28