A Rewriting Approach to Concurrent Programming Language Design and Semantics

K: A Rewriting Approach to Concurrent
Programming Language Design and Semantics
—PhD Thesis Defense—

˘ ,˘
Traian Florin Serbanuta
,

University of Illinois at Urbana-Champaign

Thesis advisor: Grigore Rosu
,

Committee members: Thomas Ball
Darko Marinov
José Meseguer
Madhusudan Parthasarathy

, ˘ ,˘
Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 1 / 39

Introduction

PhD Thesis

Rewriting is a natural environment to formally deﬁne the semantics of
real-life concurrent programming languages and to test and analyze
programs written in those languages.

, ˘ ,˘

Introduction

Motivation: pervasive computing

, ˘ ,˘

Introduction

Challenges in PL design and analysis

PLs need to be designed, updated, and extended
C# and CIL; new Java memory model, Scheme R6RS, C1X
Concurrency must become the norm

“External” non-determinism makes traditional testing difficult
Concurrency and communication (scheduler specific)
Under-specification for optimization purposes (compiler specific)

Executable formal definitions can help
Design and maintain mathematical definitions of languages
Easily test and analyze language updates or extensions
Explore and/or abstract nondeterministic executions

, ˘ ,˘

Introduction Contributions

Outline and Contributions
This dissertation re-affirms
1 Rewriting logic (RWL) as a powerful meta-logical framework for PL
Executable, with generic and efficient tool support

This dissertation proposes
2 K: the most comprehensive PL definitional framework based on RWL
Expressive, concurrent, modular, intuitive
3 A true concurrency with resource sharing semantics for K
4 K-Maude as a tool mechanizing the representation of K in RWL
Execute, explore, analyze K definitions

Demo: exploring concurrency in K-Maude
Defining dataraces and verifying datarace freeness
Experimenting with relaxed memory models (x86-TSO)

, ˘ ,˘

Introduction

My research

Rewriting & Programming languages
2010: J.LAP, J. AIHC, WRLA; 2009: J. Inf.&Comp., RV; 2008: WADT;
2007: SOS; 2006: RTA, WRLA.

Specifying and verifying concurrency
2010: J.LAP; 2008: ICSE, WMC.

Foundations
2009: J. TCS; 2006: J. Fund. Inf., FOSSACS; 2004: J. TCS.

Collaborators
Feng Chen, Camelia Chira, Chucky Ellison, Regina Frei, Mark Hills,
Giovanna Di Marzo Serugendo, José Meseguer, Andrei Popescu, Grigore
, , ˘ ,˘ , ˘
Rosu, Wolfram Schulte, Virgil Nicolae Serbanuta, Gheorghe Stefanescu.

, ˘ ,˘

Rewriting logic semantics project

[Meseguer, Rosu, 2004, 2006, 2007]
,

Goal
Advance the use of rewriting logic for deﬁning programming languages, and
for executing and analyzing programs written in them.

Some people involved in the Rewriting Logic Semantics Project
˘
Wolfgang Ahrendt, Musab Al-Turki, Marcelo d’Amorim, Irina M. Asavoae,
˘
Mihai Asavoae, Eyvind W. Axelsen, Christiano Braga, Illiano Cervesato,
Fabricio Chalub, Feng Chen, Manuel Clavel, Chucky Ellison, Azadeh
Farzan, Alejandra Garrido, Mark Hills, Michael Ilseman, Einar Broch
Johnsen, Ralph Johnson, Michael Katelman, Laurentiu Leustean, Dorel
Lucanu, Narciso Martí-Oliet, Patrick Meredith, Elena Naum, Olaf Owe,
Stefan Reich, Andreas Roth, Juan Santa-Cruz, Ralf Sasse, Wolfram
˘
Schulte, Koushik Sen, Andrei Stefanescu, Mark-Oliver Stehr, Carolyn
,

Talcott, Prasanna Thati, Ram Prasad Venkatesan, Alberto Verdejo

, ˘ ,˘


Why is RWL good for programming languages?

Executability: deﬁnitions are interpreters
Concurrency: the norm rather than the exception
Equational abstraction: collapse state space through equations
Generic tools (built around the Maude system):
Execution, tracing and debugging
State space exploration
LTL model checker
Inductive theorem prover

, ˘ ,˘


Guidelines for deﬁning programming languages in RWL

Represent the state of a running program as a conﬁguration term
Represent rules of execution as rewrite rules and equations
Equations express structural changes and irrelevant steps
Rewrite rules express relevant computational steps (transitions)
Execution: transition-sequence between equivalence classes of states
State space: transition system
amenable to exploration and model checking

, ˘ ,˘


Guidelines for deﬁning programming languages in RWL

Represent the state of a running program as a conﬁguration term
Represent rules of execution as rewrite rules and equations
Equations express structural changes and irrelevant steps
Rewrite rules express relevant computational steps (transitions)
Execution: transition-sequence between equivalence classes of states
State space: transition system
amenable to exploration and model checking

This sounds great! But. . . we need methodologies.

, ˘ ,˘

Rewriting logic semantics project From PL definitional frameworks to methodologies within RLS

PL definitional frameworks become RWL methodologies
, ˘ ,˘
[Serbanuta, Rosu, Meseguer, 2007]
,

Programming language definitional styles can be faithfully captured as a
particular definitional methodologies within RWL. (based on prior work by
[Meseguer, 1992] [[Marti-Oliet, Meseguer,1993]] [Meseguer, Braga, 2004])

Reduction
Small-Step
Semantics with
SOS
Evaluation Contexts
Big-Step Modular
SOS Rewriting Logic SOS
The Chemical
Abstract Machine
(CHAM)

Best of both worlds
Write definitions using your favorite PL framework style and notation
Execute and analyze them through their RWL representation
, ˘ ,˘


Existing definitional frameworks at a closer look

Can existing styles define (and execute) real programming languages?
No, but their combined strengths might be able to.

Shortcomings
Hard to deal with control (except for evaluation contexts)
break/continue, exceptions, halt, call/cc
Modularity issues (except for Modular SOS)
Adding new features require changing unrelated rules
Lack of semantics for true concurrency (except for CHAM)
Big-Step captures only the set of all possible results of computation
Approaches based on reduction only give interleaving semantics
Tedious to find next redex (except for evaluation contexts)
one has to write essentially the same descent rules for each construct
Inefficient for direct use as interpreters (except for Big-Step SOS)

, ˘ ,˘


Towards an ideal PL deﬁnitional framework

Reduction
Small-Step
Semantics with
SOS
Evaluation Contexts
Big-Step Modular
The Chemical Ideal PL
Abstract Machine definitional
(CHAM) framework?

Goal: search for an ideal deﬁnitional framework based on RWL
At least as expressive as Reduction with Evaluation Contexts
At least as modular as Modular SOS
At least as concurrent as the CHAM
, ˘ ,˘

The K Framework

The K Framework

Reduction
Small-Step
Semantics with
SOS
Evaluation Contexts
Big-Step Modular
The Chemical
Abstract Machine
The K Semantic
(CHAM)
Framework

The K framework
K technique: for expressive, modular, versatile, and clear PL deﬁnitions
K rewriting: more concurrent than regular rewriting
Representable in RWL for execution, testing and analysis purposes
, ˘ ,˘

The K Framework K in a nutshell

K in a nutshell

Komputations
Sequences of tasks, including syntax
Capture the sequential fragment of programming languages
Syntax annotations specify order of evaluation

Konﬁgurations
Multisets (bags) of nested cells
High potential for concurrency and modularity

K rules
Specify only what needed, precisely identify what changes
More concise, modular, and concurrent than regular rewrite rules

, ˘ ,˘


Running example: KernelC

A subset of the C programming language
Functions
Memory allocation void arrCpy(int ∗ a, int ∗ b) {
Pointer arithmetic while (∗ a ++ = ∗ b ++) {}
Input/Output
}

Extended with concurrency features
Thread creation
Lock-based synchronization
Thread join

, ˘ ,˘

Pgm ::= #include<stdio.h>#include<stdlib.h> StmtList
end module k env in

The K Framework
Module KERNELC-DESUGARED-SYNTAX
imports KERNELC-SYNTAX
macro: ! E = E ? 0 : 1
K in a nutshell rule: scanf("%d", & X )
void
X→—
I
I
•

macro: E1 && E2 = E1 ? E2 : 0
macro: E1 || E2 = E1 ? 1 : E2 rule: #include<stdio.h>#include<stdlib.h> Sts Sts
macro: if( E ) St = if( E ) St else {}
rule: { Sts } Sts
macro: NULL = 0

Running example: KernelC
macro: I () = I ( () )
rule: {} •
macro: DI L { Sts } = DI L { Sts return 0 ;}
macro: void PI = int PI rule: St Sts St Sts
macro: int * PI = int PI
macro: #include< Sts > = Sts
k
macro: E1 [ E2 ] = * E1 + E2 mem
rule: *N
macro: int * PI = E = int PI = E N→V
V
macro: E ++ = E = E + 1
end module
Module KERNELC-SEMANTICS
imports PL-CONVERSION+K+KERNELC-DESUGARED-SYNTAX k mem
Module KERNELC-SYNTAX *N=V N→—
KResult ::= List{Val} rule:
imports PL-ID+PL-INT K ::= List{Exp} | List{PointerId} | List{DeclId} | StmtList | Pgm | String V V
PointerId ::= Id | restore( Map )
| * PointerId [strict] Exp ::= Val
List{Exp} ::= List{Val} k funs
Exp ::= Int | PointerId | DeclId Val ::= Int
rule: int X Xl { Sts return E ;} •
| * Exp [ditto] | & Id • X → int X Xl { Sts return E ;}
| void
| Exp + Exp [strict]
List{Val} ::= Val
| Exp - Exp [strict] | List{Val} , List{Val} [id: () ditto assoc]  
k env
| Exp == Exp [strict] List{K} ::= Nat .. Nat 



initial configuration:  X ( Vl ) Env 
| Exp != Exp [strict]  Sts E restore( Env ) eraseKLabel ( int , Xl ) → Vl 
T  
| Exp <= Exp [strict] 
rule:  

threads  
| ! Exp 
 funs 

 X → int X Xl { Sts return E ;} 
| Exp && Exp thread*
locks cthreads
| Exp || Exp k env id
•Map •Set
| Exp ? Exp : Exp •K •Map 0 result context: int — =
“” k env
| Exp = Exp [strict(2)]
rule: int X •
| printf("%d;", Exp ) [strict] 0 X→0
| scanf("%d", Exp ) [strict] funs in out mem ptr next
| & Id •Map •List “” •Map •Map 1
k env
| Id ( List{Exp} ) [strict(2)]
rule: int X = V •
| Id () V X→V
| Exp ++ K rules:
| NULL context: * = —
rule: I1 == I2 Bool2Int ( I1 ==Int I2 ) k env
| free( Exp ) [strict]
rule: V restore( Env ) —
| (int*)malloc( Exp *sizeof(int)) [strict] rule: I1 != I2 Bool2Int ( I1 !=Int I2 ) • Env
| Exp [ Exp ]
rule: I1 + I2 I1 +Int I2
| spawn Exp  
k ptr
| acquire( Exp ) [strict] rule: I1 - I2 I1 -Int I2  
 (int*)malloc( N *sizeof(int)) • 
| release( Exp ) [strict] 
 N

N →N 
rule: I1 <= I2 Bool2Int ( I1 ≤Int I2 )  
| join( Exp ) [strict] 
rule: 


 
StmtList ::= Stmt rule: ?: if( ) else 

mem next 

 
| StmtList StmtList 

• N 

rule: if( I ) — else St St when I ==Int 0 N .. N +Nat N → 0 N +Nat N
List{Bottom} ::= Bottom
| () rule: if( I ) St else — St when notBool I ==Int 0
| List{Bottom} , List{Bottom} [id: () strict hybrid assoc] k ptr mem
rule: V ; •
List{PointerId} ::= PointerId | List{Bottom} rule: free( N ) N→N Mem
void Mem [⊥ / N .. N +Nat N ]
| List{PointerId} , List{PointerId} [id: () ditto assoc] k
•

env
List{DeclId} ::= DeclId | List{Bottom} rule: X
X→V context: spawn — ( )
| List{DeclId} , List{DeclId} [id: () ditto assoc] V
List{Exp} ::= Exp | List{PointerId} | List{DeclId} k next
rule: spawn X ( Vl ) N
| List{Exp} , List{Exp} [id: () ditto assoc] env N N +Nat 1
•

k thread
DeclId ::= int Exp X=V X→—
rule:
| void PointerId V V k id
X ( Vl ) N
Stmt ::= Exp ; [strict]
| {}
| { StmtList } k
rule: while( E ) St
| if( Exp ) Stmt if( E ) { St while( E ) St } else {}
thread
cthreads
| if( Exp ) Stmt else Stmt [strict(1)] rule:
k id •

| while( Exp ) Stmt V N N
| DeclId List{DeclId} { StmtList } k out
| DeclId List{DeclId} { StmtList return Exp ;} rule: printf("%d;", I ) S •

void S +String Int2String ( I ) +String “;”
| #include< StmtList >
k
Id ::= main join( N )
cthreads
rule: N
Pgm ::= #include<stdio.h>#include<stdlib.h> StmtList k mem in 0
end module rule: scanf("%d", N ) N→— I
Module KERNELC-DESUGARED-SYNTAX void I •

k locks
imports KERNELC-SYNTAX id
rule: acquire( N ) N → -Int 1
macro: ! E = E ? 0 : 1 void N N
k env in
macro: E1 && E2 = E1 ? E2 : 0 scanf("%d", & X ) X→— I
rule:
macro: E1 || E2 = E1 ? 1 : E2 void I •
k locks
macro: if( E ) St = if( E ) St else {} id
rule: release( N ) N→ N
macro: NULL = 0 rule: #include<stdio.h>#include<stdlib.h> Sts Sts void N -Int 1
macro: I () = I ( () )
macro: DI L { Sts } = DI L { Sts return 0 ;} rule: { Sts } Sts
macro: void PI = int PI k locks
rule: {} id
•
rule: acquire( N ) Locks •
when notBool N in keys Locks
macro: int * PI = int PI void N N→N
macro: #include< Sts > = Sts rule: St Sts St Sts
macro: E1 [ E2 ] = * E1 + E2 rule: N1 .. N1 List{K}
k •

macro: int * PI = E = int PI = E *N
mem
rule: N→V
macro: E ++ = E = E + 1 V
rule: N1 .. sNat N N ,, N1 .. N

end module end module
Module KERNELC-SEMANTICS Module KERNELC-RACE-DETECTION
k mem imports KERNELC-SEMANTICS
imports PL-CONVERSION+K+KERNELC-DESUGARED-SYNTAX initial configuration:
rule: *N=V N→—
KResult ::= List{Val}
, ˘ ,˘
Traian Florin Serbanuta (UIUC)
K ::= List{Exp} | List{PointerId} | List{DeclId} | StmtList | Pgm | String Programming Language Semantics using K
V V T
threads
15 / 39


Conﬁgurations—the running state of a program
Nested multisets (bags) of labeled cells
containing lists, sets, bags, maps and computations

Initial conﬁguration for KernelC

T

threads

thread* locks cthreads
k env id •Map •Set

•K •Map 0

funs in out mem ptr next
•Map •List •List •Map •Map 1

, ˘ ,˘


K computations and K syntax

Computations
Extend PL syntax with a “task sequentialization” operation
t1 t2 ... tn , where ti are computational tasks
Computational tasks: pieces of syntax (with holes), closures, . . .
Mostly under the hood, via intuitive PL syntax annotations

K Syntax: BNF syntax annotated with strictness
Exp ::= Id
| * Exp [strict] * ERed ERed *
| Exp = Exp [strict(2)] E = ERed ERed E=
Stmt ::= Exp ; [strict] ERed ; ERed ;
| Stmt Stmt [seqstrict] SRed S SRed S

, ˘ ,˘


Heating syntax through strictness rules

Computation

t=*x; *x=*y; *y=t;

Exp ::= Id

, ˘ ,˘



Computation

t=*x ; *x=*y; *y=t;

Exp ::= Id

, ˘ ,˘



Computation

*x t= ; *x=*y; *y=t;

Exp ::= Id

, ˘ ,˘



Computation

x * t= ; *x=*y; *y=t;

Exp ::= Id

, ˘ ,˘

The K Framework K rules

Example: running conﬁguration
Swapping the values at locations 4 and 5 in memory

void swap(int * x, int * y){
int t = * x; * x = * y; * y = t;
}
Possible Conﬁguration during a call to swap (a, b):

, ˘ ,˘


Example: running conﬁguration

Strictness rules (from annotations) extract the redex
How do we specify next step?

, ˘ ,˘


K rules: expressing natural language into rules
Focusing on the relevant part

Reading from environment
If a local variable X is the next thing to be processed . . .
. . . and if X is mapped to a value V in the environment . . .
. . . then process X , replacing it by V

, ˘ ,˘


Unnecessary parts of the cells are abstracted away


, ˘ ,˘


Underlining what to replace, writing the replacement under the line


, ˘ ,˘


Conﬁguration Abstraction: Keep only the relevant cells


, ˘ ,˘


Generalize the concrete instance


, ˘ ,˘


Voilà!


, ˘ ,˘


Summary

k
env
X
X →V
V

, ˘ ,˘


Conﬁguration abstraction enhances modularity
At least as modular as Modular SOS

k
env
X
X →V
V

T

thread

k
t *5= ; env( a → 4 b → 5 )

state
env mem
x→4 t→1 y→5 4→7 5→7

, ˘ ,˘


Applying K rules: Reading from environment

k
env
X
X →V
V

T

k
t *5= ; env( a → 4 b → 5 )

env mem
x→4 t→1 y→5 4→7 5→7

, ˘ ,˘


Applying K rules: Reading from environment

k
env
X
X →V
V

T

k
1 *5= ; env( a → 4 b → 5 )

env mem
x→4 t→1 y→5 4→7 5→7

, ˘ ,˘


Applying K rules: Strictness of assignment

Exp ::= Exp = Exp [strict(2)]
which is syntactic sugar for:

E = Redex Redex E=

T

k
1 *5= ; env( a → 4 b → 5 )

env mem
x→4 t→1 y→5 4→7 5→7

, ˘ ,˘


Applying K rules: Strictness of assignment

Exp ::= Exp = Exp [strict(2)]
which is syntactic sugar for:

E = Redex Redex E=

T

k
*5=1 ; env( a → 4 b → 5 )

env mem
x→4 t→1 y→5 4→7 5→7

, ˘ ,˘


Applying K rules: Updating memory

k mem
*N=V N→ _
V V

T

k
*5=1 ; env( a → 4 b → 5 )

env mem
x→4 t→1 y→5 4→7 5→7

, ˘ ,˘


Applying K rules: Updating memory

k mem
*N=V N→ _
V V

T

k
1 ; env( a → 4 b → 5 )

env mem
x→4 t→1 y→5 4→7 5→1

, ˘ ,˘


Applying K rules: Semantics for expression statements

Strictness : Stmt ::= Exp ; [strict]
Semantic rule: V ; skip

T

k
1 ; env( a → 4 b → 5 )

env mem
x→4 t→1 y→5 4→7 5→1

, ˘ ,˘


Applying K rules: Semantics for expression statements

Strictness : Stmt ::= Exp ; [strict]
Semantic rule: V ; skip

T

k
skip env( a → 4 b → 5 )

env mem
x→4 t→1 y→5 4→7 5→1

, ˘ ,˘


Applying K rules: Recovering environment

k env
V env( Env ) _
• Env

T

k
skip env( a → 4 b → 5 )

env mem
x→4 t→1 y→5 4→7 5→1

, ˘ ,˘


Applying K rules: Recovering environment

k env
V env( Env ) _
• Env

T

k
skip

env mem
a→4 b→5 4→7 5→1

, ˘ ,˘

The K Framework Strengths of K

K’s definitional power
More expressive than Reduction with Evaluation Contexts

Some of K’s strengths
Dealing with control
Task synchronization
Defining reflective features

, ˘ ,˘


Deﬁnitional Power: Control

Call with current continuation

k
Passing computation as value: callcc V K
V cc (K )

k
Applying computation as function: cc (K ) V _
V K

Impossible to capture in frameworks without evaluation contexts
Why? Execution context is logical context, not observable from within

, ˘ ,˘


Deﬁnitional Power: Synchronization

Synchronous communication

agent agent

k k
me me
sendSynch V to N2 receiveFrom N1
N1 N2
skip V

Hard, if not impossible to capture in other deﬁnitional frameworks
(might work for toy languages: CCS, π-calculus)
Both redexes must be matched simultaneously
Easy in K as redex is always at top of computation

, ˘ ,˘


Definitional Power: Syntactic Reflection

K Syntax = AST
K ::= KLabel (List {K }) | •K | K K
List {K } ::= K | •List {K } | List {K } , List {K }
Everything else (language construct, builtin constant) is a K label

a + 3 ≡ _ + _(a (•List {K } ) , 3(•List {K }))
Reflection through AST manipulation
Generic AST visitor pattern
Code generation: quote/unquote
Binder independent substitution
Check dissertation for more details

, ˘ ,˘

The K Framework Concurrency

The concurrency of the K framework

Truly concurrent (even more concurrent than the CHAM framework)
Captures concurrency with sharing of resources.

, ˘ ,˘


K rules enhance concurrency
Concurrent reads

k
mem
*N
N→V
V

T

k k
*3 ··· *3 ···

mem
2→5 3→1 4→6

, ˘ ,˘


Concurrent reads

k
mem
*N
N→V
V

T

k k
1 ··· 1 ···
mem
2→5 3→1 4→6

, ˘ ,˘


Concurrent updates (on distinct locations)

k mem
*N=V N→ _
V V

T

k k
*2=9 ··· *3=0 ···
mem
2→5 3→1 4→6

, ˘ ,˘


Concurrent updates (on distinct locations)

k mem
*N=V N→ _
V V

T

k k
9 ··· 0 ···
mem
2→9 3→0 4→6

, ˘ ,˘


No dataraces: rule instances can overlap only on read-only part

k mem k
mem
*N=V N→ _ *N
N→V
V V V

T

k k
*3=0 ··· *3 ···

mem
2→5 3→1 4→6

, ˘ ,˘

Formally capturing the concurrency of K

Formally capturing the concurrency of K

Idea: Give semantics to K rewriting through graph rewriting
K rules resemble graph rewriting rules
Graph rewriting captures concurrency with sharing of context

Results: A new formalism of term-graph rewriting
Sound and complete w.r.t. term rewriting
Capturing the intended concurrency of K rewriting

, ˘ ,˘

Formally capturing the concurrency of K K graph rewriting

K graph rules: a new kind of term graph rewriting rules
K rule ρ
h( x , _ , 1)
g (x , x ) 0

Direct representation as a rewrite rule K2R (ρ)

h (x , y , 1) → h (g (x , x ), y , 0)

Corresponding graph rewrite rule K2G (ρ)
s s s

1 h3 h 1h 3
⊃ ⊂
x:s int x:s int s int int
1 1 g 0 1
1 2
x:s
, ˘ ,˘


K rewriting

Deﬁnition
Let S be a K rewrite system and t be a term. Then

S K2G (S)
t ≡≡
≡≡ t iff K2G (t ) = = ⇒ H such that term(H ) = t
==
K Graph

Theorem (Correctness w.r.t. rewriting)
ρ K2R (ρ)
Soundness: If t ≡≡
≡≡ t then t = = ⇒ t .
==
K Rew
K2R (ρ) ρ
Completeness: If t = = ⇒ t then t
== ≡≡
≡≡ t .
Rew K
ρ1 +···+ρn ρ1 ∗ ρn ∗ ∗
Serializability: If t ≡ ≡≡≡≡≡
≡≡≡≡≡ t then t ≡≡
≡≡ · · · ≡≡≡ t (and thus, t = ⇒ t ).
≡ =
K K K Rew

, ˘ ,˘


Instead of proof

Quite technical and complex
12 pages of deﬁnitions, constructions, and preparatory results

Getting there
K term graphs and K graph rewrite rules
K term graphs are stable under concurrent applications of K rules
If their instances only overlap on read-only part
If they do not introduce cycles
Serializability based on graph rewriting serializability
[Ehrig, Kreowski, 1976]
K graph rewriting conservatively extends Jungle rewriting
Jungle rewriting is sound and complete w.r.t. rewriting
[Holland, Plump, 1991; Plump 1999]

, ˘ ,˘

Representing K into RWL

Core of the K-Maude tool

Faithfully, in two steps
Represent K rewriting as K graph rewriting
RWL captures graph rewriting as theories over concurrent objects
Theoretical, non executable
Useful to reason about the amount of concurrency in a K deﬁnition

Directly—Implemented in the K-Maude tool
Straight-forward, forgetting read-only information of K rules
Executable, with full access to rewriting logic’s tools
Loses the one-step concurrency of K
Nevertheless, it is sound for all other analysis purposes

, ˘ ,˘


Direct embedding of K into RWL (core of K-Maude)
Dereferencing rule
k
mem
*N
N→V
V

T

threads

thread* locks cthreads
k env id •Map •Set

•K •Map 0

funs in out mem ptr next
•Map •List •List •Map •Map 1

, ˘ ,˘


Dereferencing rule
k
mem
*N
N→V
V

Conﬁguration-concretized version of the rule

threads

thread

k mem
*N N→V
V

, ˘ ,˘


Dereferencing rule
k
mem
*N
N→V
V

Flattening the K rule to a rewrite rule

rl <threads> <thread> <k> * N ?1:K </k> ?2:Bag </thread> ?3:Bag </threads>
<mem> N → V ?4:Map </mem>
=> <threads> <thread> <k> V ?1:K </k> ?2:Bag </thread> ?3:Bag </threads>
<mem> N → V ?4:Map </mem>

, ˘ ,˘

Representing K into RWL K-Maude

K-Maude overview [Serbanuta, Rosu, 2010]
˘ ˘ , , ,

K-Maude compiler: 22 stages ∼ 8k lines of Maude code
Transforming K rules in rewrite rules (6 stages)
Strictness rules generation (3 stages)
Flattening syntax to AST form (10 stages)
Interface (3 stages)

K-LTEX compiler—typesetting ASCII K
A

Graphical representation, for presentations (like this defense)
Mathematical representation, for papers (like the dissertation)

, ˘ ,˘


K-Maude Demo?
From PL deﬁnitions to runtime analysis tools

, ˘ ,˘


K-Maude Demo: Datarace freeness

Begin with a definition of KernelC, a subset of C
functions, memory allocation, pointers, input/output
Extend it with concurrency features (threads, locks, join)
without changing anything but the configuration
Specify dataraces and explore executions for datarace freeness
adding only two structural rules, for write-write and write-read conflicts
Case study: Bank account with buggy transfer function
Detect the race using a test driver
Fix the race and verify the fix
Show that the fix introduces a deadlock
Fix the fix and verify it is now datarace and deadlock free

, ˘ ,˘


K-Maude Demo: Experimenting with memory models

Change the memory model for concurrent KernelC
Use a relaxed memory model inspired by x86-TSO
Threads act like processors, local variables as registers
Synchronization constructs (thread create, end, join) generate fences
Rules faithfully capture the natural language description
Only the rules speciﬁcally involved need to be changed
Case study: Analyzing Peterson’s algorithm on both memory models
ﬁrst model, being sequentially consistent, ensures mutual exclusion
second model fails to ensure it

, ˘ ,˘


K-Maude community
http://k-framework.googlecode.com

Current K-Maude projects
C Chucky Ellison
Haskell Michael Ilseman, David Lazar
Javascript Maurice Rabb
Scheme Patrick Meredith
X10 Milos Gligoric

˘
Matching Logic Elena Naum, Andrei Stefanescu
,

˘ ˘
CEGAR Irina Asavoae, Mihail Asavoae

Teaching Dorel Lucanu, Grigore Rosu
,

Interface Andrei Arusoaie, Michael Ilseman
, ˘ ,˘

Conclusions

Summary of contributions

K: a framework for defining real programming languages
Expressive—at least as Reduction with evaluation contexts
Modular—at least as Modular SOS
Concurrent—more than CHAM
Concise, intuitive

K-Maude: a tool for executing and analyzing K definitions
K definitions become testing and analysis tools
Strengthens the thesis that RWL is amenable for PL definitions

, ˘ ,˘

Conclusions Related work

Related work using K

Deﬁnitions of real languages “by the book”
Java [Farzan, Chen, Meseguer, Rosu, 2004]
,

Scheme [Meredith, Hills, Rosu, 2007]
,

Verilog [Meredith, Katelman, Meseguer, Rosu, 2010]
,

C [Ellison, Rosu, 2011?]
,

Analysis tools and techniques
Static Policy Checker for C [Hills, Chen, Rosu, 2008]
,

Memory Safety [Rosu, Schulte, Serbanut, a, 2009]
, , ˘ ˘
Type Soundness [Ellison, Serbanut, a, Rosu, 2008]
, ˘ ˘ ,

Matching Logic [Rosu, Ellison, Schulte, 2010]
,

CEGAR with predicate abstraction [Asavoae, Asavoae, 2010]
˘ ˘

, ˘ ,˘

Conclusions Future Work

Future Work

Rewriting & Programming languages
Long list of feature requests for K-Maude
Use of K as a programming language
Compiling K deﬁnitions for faster (and concurrent) execution
Proving meta-properties about languages

Specifying and verifying concurrency
Relaxed memory models

Foundations
Explore non-serializable concurrency for rewriting
Models for K deﬁnitions

, ˘ ,˘

A Rewriting Approach to Concurrent Programming Language Design and Semantics

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to A Rewriting Approach to Concurrent Programming Language Design and Semantics

Similar to A Rewriting Approach to Concurrent Programming Language Design and Semantics (20)

Recently uploaded

Recently uploaded (20)

A Rewriting Approach to Concurrent Programming Language Design and Semantics