k: a rewriting approach to concurrent programming...

K: A Rewriting Approach to ConcurrentProgramming Language Design and Semantics

—PhD Thesis Defense—

Traian Florin S, erbanut,a

University of Illinois at Urbana-Champaign

Thesis advisor: Grigore Ros, uCommittee members: Thomas Ball

Darko MarinovJosé MeseguerMadhusudan Parthasarathy

Traian Florin S, erbanut,a (UIUC) Programming Language Semantics using K 1 / 39

PhD Thesis, University of Illinois, December 2010

Introduction

PhD Thesis

Rewriting is a natural environment to formally define the semantics ofreal-life concurrent programming languages and to test and analyzeprograms written in those languages.



Introduction

Motivation: pervasive computing



http://www.flickr.com/photos/mohanababu_d/4514047428/

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-affirms1 Rewriting logic (RWL) as a powerful meta-logical framework for PL

Executable, with generic and efficient tool support

This dissertation proposes2 K: the most comprehensive PL definitional framework based on RWL

Expressive, concurrent, modular, intuitive3 A true concurrency with resource sharing semantics for K4 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.

Foundations2009: J. TCS; 2006: J. Fund. Inf., FOSSACS; 2004: J. TCS.

CollaboratorsFeng Chen, Camelia Chira, Chucky Ellison, Regina Frei, Mark Hills,Giovanna Di Marzo Serugendo, José Meseguer, Andrei Popescu, GrigoreRos, u, Wolfram Schulte, Virgil Nicolae S, erbanut,a, Gheorghe S, tefanescu.



Rewriting logic semantics project

Rewriting logic semantics project[Meseguer, Ros, u, 2004, 2006, 2007]

GoalAdvance the use of rewriting logic for defining programming languages, andfor 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, AzadehFarzan, Alejandra Garrido, Mark Hills, Michael Ilseman, Einar BrochJohnsen, Ralph Johnson, Michael Katelman, Laurentiu Leustean, DorelLucanu, Narciso Martí-Oliet, Patrick Meredith, Elena Naum, Olaf Owe,Stefan Reich, Andreas Roth, Juan Santa-Cruz, Ralf Sasse, WolframSchulte, Koushik Sen, Andrei S, tefanescu, Mark-Oliver Stehr, CarolynTalcott, Prasanna Thati, Ram Prasad Venkatesan, Alberto Verdejo




Why is RWL good for programming languages?

Executability: definitions are interpreters

Concurrency: the norm rather than the exception

Equational abstraction: collapse state space through equationsGeneric tools (built around the Maude system):

Execution, tracing and debuggingState space explorationLTL model checkerInductive theorem prover




Guidelines for defining programming languages in RWL

Represent the state of a running program as a configuration termRepresent rules of execution as rewrite rules and equations

Equations express structural changes and irrelevant stepsRewrite rules express relevant computational steps (transitions)

Execution: transition-sequence between equivalence classes of statesState 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[S, erbanut,a, Ros, u, Meseguer, 2007]

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

Rewriting LogicBig-Step SOS

Modular SOS

The Chemical Abstract Machine

(CHAM)

Reduction Semantics with

Evaluation Contexts

Small-StepSOS

Best of both worldsWrite definitions using your favorite PL framework style and notationExecute 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 computationApproaches 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 definitional framework


Modular SOS


(CHAM)


Evaluation Contexts

Small-StepSOS

Ideal PL definitional framework?

Goal: search for an ideal definitional framework based on RWLAt 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


Modular SOS


(CHAM)


Evaluation Contexts

Small-StepSOS

The K Semantic

Framework

The K frameworkK technique: for expressive, modular, versatile, and clear PL definitions

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

Konfigurations

Multisets (bags) of nested cells

High potential for concurrency and modularity

K rulesSpecify 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

Pointer arithmetic

Input/Output

void arrCpy(int ∗ a, int ∗ b) {while (∗ a ++ = ∗ b ++) {}}

Extended with concurrency features

Thread creation

Lock-based synchronization

Thread join




Running example: KernelCModule KERNELC-SYNTAX

imports PL-ID+PL-INTPointerId ::= Id

| * PointerId [strict]Exp ::= Int | PointerId | DeclId

| * Exp [ditto]| Exp + Exp [strict]| Exp - Exp [strict]| Exp == Exp [strict]| Exp != Exp [strict]| Exp <= Exp [strict]| ! Exp| Exp && Exp| Exp || Exp| Exp ? Exp : Exp| Exp = Exp [strict(2)]| printf("%d;", Exp ) [strict]| scanf("%d", Exp ) [strict]| & Id| Id ( List{Exp} ) [strict(2)]| Id ()

| Exp ++

| NULL| free( Exp ) [strict]| (int*)malloc( Exp *sizeof(int)) [strict]| Exp [ Exp ]

| spawn Exp| acquire( Exp ) [strict]| release( Exp ) [strict]| join( Exp ) [strict]

StmtList ::= Stmt| StmtList StmtList

List{Bottom} ::= Bottom| ()| List{Bottom} , List{Bottom} [id: () strict hybrid assoc]

List{PointerId} ::= PointerId | List{Bottom}| List{PointerId} , List{PointerId} [id: () ditto assoc]

List{DeclId} ::= DeclId | List{Bottom}| List{DeclId} , List{DeclId} [id: () ditto assoc]

List{Exp} ::= Exp | List{PointerId} | List{DeclId}| List{Exp} , List{Exp} [id: () ditto assoc]

DeclId ::= int Exp| void PointerId

Stmt ::= Exp ; [strict]| {}| { StmtList }| if( Exp ) Stmt| if( Exp ) Stmt else Stmt [strict(1)]| while( Exp ) Stmt| DeclId List{DeclId} { StmtList }| DeclId List{DeclId} { StmtList return Exp ;}| #include< StmtList >

Id ::= main

Pgm ::= #include<stdio.h>#include<stdlib.h> StmtListend moduleModule KERNELC-DESUGARED-SYNTAX

imports KERNELC-SYNTAXmacro: ! E = E ? 0 : 1macro: E1 && E2 = E1 ? E2 : 0macro: E1 || E2 = E1 ? 1 : E2

macro: if( E ) St = if( E ) St else {}macro: NULL = 0macro: I () = I ( () )

macro: DI L { Sts } = DI L { Sts return 0 ;}macro: void PI = int PImacro: int * PI = int PImacro: #include< Sts > = Stsmacro: E1 [ E2 ] = * E1 + E2

macro: int * PI = E = int PI = Emacro: E ++ = E = E + 1

end moduleModule KERNELC-SEMANTICS

imports PL-CONVERSION+K+KERNELC-DESUGARED-SYNTAXKResult ::= List{Val}K ::= List{Exp} | List{PointerId} | List{DeclId} | StmtList | Pgm | String

| restore( Map )

Exp ::= ValList{Exp} ::= List{Val}Val ::= Int

| & Id| void

List{Val} ::= Val| List{Val} , List{Val} [id: () ditto assoc]

List{K} ::= Nat .. Natinitial configuration:

•K

k

•Map

env

0

id

thread*

threads

•Map

locks

•Set

cthreads

•Map

funs

•List

in

“”

out

•Map

mem

•Map

ptr

1

next

T

“”

result

K rules:context: * ! = —rule: I1 == I2 ! Bool2Int ( I1 ==Int I2 )

rule: I1 != I2 ! Bool2Int ( I1 !=Int I2 )

rule: I1 + I2 ! I1 +Int I2

rule: I1 - I2 ! I1 -Int I2

rule: I1 <= I2 ! Bool2Int ( I1 !Int I2 )

rule: ? : ! if( ) else

rule: if( I ) — else St ! St when I ==Int 0

rule: if( I ) St else — ! St when notBool I ==Int 0

rule: V ; ! •

rule: XV

k

X "# V

env

rule: X = VV

k

X "# —V

env

rule: while( E ) Stif( E ) { St while( E ) St } else {}

k

rule: printf("%d;", I )void

k

SS +String Int2String ( I ) +String “;”

out

rule: scanf("%d", N )

void

k

N "# —I

mem

I•

in

rule: scanf("%d", & X )

void

k

X "# —I

env

I•

in

rule: #include<stdio.h>#include<stdlib.h> Sts ! Sts

rule: { Sts } ! Sts

rule: {} ! •

rule: St Sts ! St ! Sts

rule: * NV

k

N "# V

mem

rule: * N = VV

k

N "# —V

mem

rule: int X Xl { Sts return E ;}•

k

•

X "# int X Xl { Sts return E ;}

funs

rule:

!""""""""""#

X ( Vl )Sts ! E ! restore( Env )

k

EnveraseKLabel ( int , Xl ) "# Vl

env

X "# int X Xl { Sts return E ;}funs

$%%%%%%%%%%&

context: int — = !

rule: int X0

k

•

X "# 0

env

rule: int X = VV

k

•

X "# V

env

rule: V ! restore( Env )•

k

—Env

env

rule:

!""""""""""""#

(int*)malloc( N *sizeof(int))

N !

k

•

N ! "# N

ptr

•

N ! .. N +Nat N ! "# 0

mem

N !

N +Nat N !

next

$%%%%%%%%%%%%&

rule: free( N )

void

k

N "# N !

•

ptr

MemMem [$ / N .. N +Nat N ! ]

mem

context: spawn — ( ! )

rule: spawn X ( Vl )N

k

NN +Nat 1

next

•

X ( Vl )

k

N

id

thread

rule:V

k

N

id

thread

•

•

N

cthreads

rule: join( N )

0

k

N

cthreads

rule: acquire( N )

void

k

N !id

N "# -Int 1N !

locks

rule: release( N )

void

k

N !id

N "# N !

-Int 1

locks

rule: acquire( N )

void

k

N !id

Locks •

N "# N !

locks

when notBool N in keys Locks

rule: N1 .. N1 ! •List{K}

rule: N1 .. sNat N ! N ,, N1 .. N

end moduleModule KERNELC-RACE-DETECTION

imports KERNELC-SEMANTICSinitial configuration:

•K

k?

•K

race?

•Map

env

0

id

thread*

threads

•Set

cthreads

•Map

funs

•List

in

“”

out

•Map

mem

•Map

ptr

•Map

locks

1

next

T

“”

result

K rules:rule: < k

race> * N = E ...</ k

race> < k

race> * N = E! ...</ k

race>

rule: < krace

> * N = E ...</ krace

> < krace

> * N ...</ krace

>

rule: < TraceDetected

>... K

race...</ T

raceDetected

>

end module

Module KERNELC-SYNTAXimports PL-ID+PL-INTPointerId ::= Id



| Exp ++










Id ::= main








| restore( Map )


| & Id| void



•K

k

•Map

env

0

id

thread*

threads

•Map

locks

•Set

cthreads

•Map

funs

•List

in

“”

out

•Map

mem

•Map

ptr

1

next

T

“”

result









rule: V ; ! •

rule: XV

k

X "# V

env

rule: X = VV

k

X "# —V

env


k


k


out


void

k

N "# —I

mem

I•

in


void

k

X "# —I

env

I•

in


rule: { Sts } ! Sts

rule: {} ! •


rule: * NV

k

N "# V

mem

rule: * N = VV

k

N "# —V

mem


k

•


funs

rule:

!""""""""""#


k


env


$%%%%%%%%%%&


rule: int X0

k

•

X "# 0

env

rule: int X = VV

k

•

X "# V

env


k

—Env

env

rule:

!""""""""""""#


N !

k

•

N ! "# N

ptr

•

N ! .. N +Nat N ! "# 0

mem

N !

N +Nat N !

next

$%%%%%%%%%%%%&

rule: free( N )

void

k

N "# N !

•

ptr


mem



k

NN +Nat 1

next

•

X ( Vl )

k

N

id

thread

rule:V

k

N

id

thread

•

•

N

cthreads

rule: join( N )

0

k

N

cthreads

rule: acquire( N )

void

k

N !id

N "# -Int 1N !

locks

rule: release( N )

void

k

N !id

N "# N !

-Int 1

locks

rule: acquire( N )

void

k

N !id

Locks •

N "# N !

locks



rule: N1 .. sNat N ! N ,, N1 .. N



•K

k?

•K

race?

•Map

env

0

id

thread*

threads

•Set

cthreads

•Map

funs

•List

in

“”

out

•Map

mem

•Map

ptr

•Map

locks

1

next

T

“”

result

K rules:rule: < k

race> * N = E ...</ k

race> < k

race> * N = E! ...</ k

race>

rule: < krace

> * N = E ...</ krace

> < krace

> * N ...</ krace

>


>... K

race...</ T

raceDetected

>

end module

Module KERNELC-SYNTAXimports PL-ID+PL-INTPointerId ::= Id



| Exp ++










Id ::= main








| restore( Map )


| & Id| void



•K

k

•Map

env

0

id

thread*

threads

•Map

locks

•Set

cthreads

•Map

funs

•List

in

“”

out

•Map

mem

•Map

ptr

1

next

T

“”

result









rule: V ; ! •

rule: XV

k

X "# V

env

rule: X = VV

k

X "# —V

env


k


k


out


void

k

N "# —I

mem

I•

in


void

k

X "# —I

env

I•

in


rule: { Sts } ! Sts

rule: {} ! •


rule: * NV

k

N "# V

mem

rule: * N = VV

k

N "# —V

mem


k

•


funs

rule:

!""""""""""#


k


env


$%%%%%%%%%%&


rule: int X0

k

•

X "# 0

env

rule: int X = VV

k

•

X "# V

env


k

—Env

env

rule:

!""""""""""""#


N !

k

•

N ! "# N

ptr

•

N ! .. N +Nat N ! "# 0

mem

N !

N +Nat N !

next

$%%%%%%%%%%%%&

rule: free( N )

void

k

N "# N !

•

ptr


mem



k

NN +Nat 1

next

•

X ( Vl )

k

N

id

thread

rule:V

k

N

id

thread

•

•

N

cthreads

rule: join( N )

0

k

N

cthreads

rule: acquire( N )

void

k

N !id

N "# -Int 1N !

locks

rule: release( N )

void

k

N !id

N "# N !

-Int 1

locks

rule: acquire( N )

void

k

N !id

Locks •

N "# N !

locks



rule: N1 .. sNat N ! N ,, N1 .. N



•K

k?

•K

race?

•Map

env

0

id

thread*

threads

•Set

cthreads

•Map

funs

•List

in

“”

out

•Map

mem

•Map

ptr

•Map

locks

1

next

T

“”

result

K rules:rule: < k

race> * N = E ...</ k

race> < k

race> * N = E! ...</ k

race>

rule: < krace

> * N = E ...</ krace

> < krace

> * N ...</ krace

>


>... K

race...</ T

raceDetected

>

end module




Configurations—the running state of a program

Nested multisets (bags) of labeled cellscontaining lists, sets, bags, maps and computations

Initial configuration for KernelC

•K

k

•Map

env

0

id

thread*

threads

•Map

locks

•Set

cthreads

•Map

funs

•List

in

•List

out

•Map

mem

•Map

ptr

1

next

T




K computations and K syntax

Computations

Extend PL syntax with a “task sequentialization” operationt1 y t2 y . . .y 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]| Exp = Exp [strict(2)]

Stmt ::= Exp ; [strict]| Stmt Stmt [seqstrict]

* ERed ERed y * �E = ERed ERed y E = �ERed ; ERed y � ;SRed S SRed y � S




Heating syntax through strictness rules

Computation

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









Computation

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









Computation

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









Computation

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









Computation

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







The K Framework K rules

Example: running configurationSwapping the values at locations 4 and 5 in memory

void swap(int * x, int * y){int t = * x; * x = * y; * y = t;}

Possible Configuration during a call to swap (a, b):




Example: running configuration

Strictness rules (from annotations) extract the redex

How do we specify next step?




K rules: expressing natural language into rulesFocusing 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




K rules: expressing natural language into rulesUnnecessary parts of the cells are abstracted away






K rules: expressing natural language into rulesUnderlining what to replace, writing the replacement under the line






K rules: expressing natural language into rulesConfiguration Abstraction: Keep only the relevant cells






K rules: expressing natural language into rulesGeneralize the concrete instance






K rules: expressing natural language into rulesVoilà!






K rules: expressing natural language into rulesSummary


XV

k

X 7→ V

env




Configuration abstraction enhances modularityAt least as modular as Modular SOS


XV

k

X 7→ V

env

ty * 5 = �y � ;y env( a 7→ 4 b 7→ 5 )

k

thread

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

env

4 7→ 7 5 7→ 7

mem

state

T




Applying K rules: Reading from environment

XV

k

X 7→ V

env

t y * 5 = �y � ; y env( a 7→ 4 b 7→ 5 )

k

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

env

4 7→ 7 5 7→ 7

mem

T




Applying K rules: Reading from environment

XV

k

X 7→ V

env

1y * 5 = �y � ; y env( a 7→ 4 b 7→ 5 )

k

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

env

4 7→ 7 5 7→ 7

mem

T




Applying K rules: Strictness of assignment

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

E = Redex Redex y E = �

1y * 5 = �y � ; y env( a 7→ 4 b 7→ 5 )

k

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

env

4 7→ 7 5 7→ 7

mem

T




Applying K rules: Strictness of assignment

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

E = Redex Redex y E = �

* 5 = 1y � ; y env( a 7→ 4 b 7→ 5 )

k

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

env

4 7→ 7 5 7→ 7

mem

T




Applying K rules: Updating memory

* N = VV

kN 7→ _

V

mem

* 5 = 1y � ; y env( a 7→ 4 b 7→ 5 )

k

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

env

4 7→ 7 5 7→ 7

mem

T




Applying K rules: Updating memory

* N = VV

kN 7→ _

V

mem

1y � ; y env( a 7→ 4 b 7→ 5 )

k

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

env

4 7→ 7 5 7→ 1

mem

T




Applying K rules: Semantics for expression statements

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

1y � ; y env( a 7→ 4 b 7→ 5 )

k

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

env

4 7→ 7 5 7→ 1

mem

T




Applying K rules: Semantics for expression statements

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

skip y env( a 7→ 4 b 7→ 5 )

k

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

env

4 7→ 7 5 7→ 1

mem

T




Applying K rules: Recovering environment

V y env( Env )•

k_

Env

env

skip y env( a 7→ 4 b 7→ 5 )

k

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

env

4 7→ 7 5 7→ 1

mem

T




Applying K rules: Recovering environment

V y env( Env )•

k_

Env

env

skip

k

a 7→ 4 b 7→ 5

env

4 7→ 7 5 7→ 1

mem

T



The K Framework Strengths of K

K’s definitional powerMore expressive than Reduction with Evaluation Contexts

Some of K’s strengths

Dealing with control

Task synchronization

Defining reflective features




Definitional Power: Control

Call with current continuation

Passing computation as value: callcc VV cc(K)

y Kk

Applying computation as function: cc(K) V y _V y K

k

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




Definitional Power: Synchronization

Synchronous communication

N1

mesendSynch V to N2

skip

k

agent

N2

mereceiveFrom N1

V

k

agent

Hard, if not impossible to capture in other definitional frameworks(might work for toy languages: CCS, π-calculus)

Both redexes must be matched simultaneouslyEasy in K as redex is always at top of computation




Definitional Power: Syntactic Reflection

K Syntax = AST

K ::= KLabel(List{K }) | •K | K y KList{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

* NV

k

N 7→ V

mem

* 3 y · · ·

k

* 3 y · · ·

k

2 7→ 5 3 7→ 1 4 7→ 6

mem

T





Concurrent reads

* NV

k

N 7→ V

mem

1y · · ·

k

1y · · ·

k

2 7→ 5 3 7→ 1 4 7→ 6

mem

T





Concurrent updates (on distinct locations)

* N = VV

kN 7→ _

V

mem

* 2 = 9y · · ·

k

* 3 = 0y · · ·

k

2 7→ 5 3 7→ 1 4 7→ 6

mem

T





Concurrent updates (on distinct locations)

* N = VV

kN 7→ _

V

mem

9y · · ·

k

0y · · ·

k

2 7→ 9 3 7→ 0 4 7→ 6

mem

T





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

* N = VV

kN 7→ _

V

mem

* NV

k

N 7→ V

mem

* 3 = 0y · · ·

k

* 3 y · · ·

k

2 7→ 5 3 7→ 1 4 7→ 6

mem

T



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( xg(x, x)

, _ , 10)

Direct representation as a rewrite rule K2R(ρ)

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

Corresponding graph rewrite rule K2G(ρ)

s

h

x:s1

int

1

3⊃

s

h

x:s int

1

⊂

s

h

s1

gint

3

0x:s

int

11 2




K rewriting

DefinitionLet S be a K rewrite system and t be a term. Then

tS≡≡≡≡≡�K

t ′ iff K2G(t)K2G(S)====⇒

GraphH such that term(H) = t ′

Theorem (Correctness w.r.t. rewriting)

Soundness: If tρ≡≡≡≡≡�K

t ′ then tK2R(ρ)====⇒

Rewt ′.

Completeness: If tK2R(ρ)====⇒

Rewt ′ then t

ρ≡≡≡≡≡�K

t ′.

Serializability: If tρ1+···+ρn≡≡≡≡≡≡≡≡≡≡≡≡�K

t ′ then tρ1∗

≡≡≡≡≡�K· · ·

ρn∗

≡≡≡≡≡�K

t ′ (and thus, t∗

==⇒Rew

t ′).




Instead of proof

Quite technical and complex

12 pages of definitions, constructions, and preparatory results

Getting there

K term graphs and K graph rewrite rulesK term graphs are stable under concurrent applications of K rules

If their instances only overlap on read-only partIf 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

Representing K into RWLCore of the K-Maude tool

Faithfully, in two steps

Represent K rewriting as K graph rewritingRWL captures graph rewriting as theories over concurrent objects

Theoretical, non executable

Useful to reason about the amount of concurrency in a K definition

Directly—Implemented in the K-Maude tool

Straight-forward, forgetting read-only information of K rules

Executable, with full access to rewriting logic’s toolsLoses 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

* NV

k

N 7→ V

mem

•K

k

•Map

env

0

id

thread*

threads

•Map

locks

•Set

cthreads

•Map

funs

•List

in

•List

out

•Map

mem

•Map

ptr

1

next

T





Dereferencing rule

* NV

k

N 7→ V

mem

Configuration-concretized version of the rule

* NV

k

thread

threads

N 7→ V

mem





Dereferencing rule

* NV

k

N 7→ V

mem

Flattening the K rule to a rewrite rule

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

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



Representing K into RWL K-Maude

K-Maude overview [S, erbanut,a, Ros, u, 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-LATEX compiler—typesetting ASCII K

Graphical representation, for presentations (like this defense)

Mathematical representation, for papers (like the dissertation)




K-Maude Demo?From PL definitions to runtime analysis tools




K-Maude Demo: Datarace freeness

Begin with a definition of KernelC, a subset of Cfunctions, 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 freenessadding only two structural rules, for write-write and write-read conflicts

Case study: Bank account with buggy transfer functionDetect the race using a test driverFix the race and verify the fixShow that the fix introduces a deadlockFix the fix and verify it is now datarace and deadlock free




K-Maude Demo: Experimenting with memory models

Change the memory model for concurrent KernelCUse a relaxed memory model inspired by x86-TSO

Threads act like processors, local variables as registersSynchronization constructs (thread create, end, join) generate fencesRules faithfully capture the natural language descriptionOnly the rules specifically involved need to be changed

Case study: Analyzing Peterson’s algorithm on both memory modelsfirst model, being sequentially consistent, ensures mutual exclusionsecond model fails to ensure it




K-Maude communityhttp://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 S, tefanescu

CEGAR Irina Asavoae, Mihail Asavoae

Teaching Dorel Lucanu, Grigore Ros, u

Interface Andrei Arusoaie, Michael Ilseman



http://k-framework.googlecode.com

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

Definitions of real languages “by the book”

Java [Farzan, Chen, Meseguer, Ros, u, 2004 ]

Scheme [Meredith, Hills, Ros, u, 2007]

Verilog [Meredith, Katelman, Meseguer, Ros, u, 2010]

C [Ellison, Ros, u, 2011?]

Analysis tools and techniques

Static Policy Checker for C [Hills, Chen, Ros, u, 2008]

Memory Safety [Ros, u, Schulte, S, erbanut,a, 2009]

Type Soundness [Ellison, S, erbanut,a, Ros, u, 2008]

Matching Logic [Ros, u, 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-MaudeUse of K as a programming language

Compiling K definitions for faster (and concurrent) execution

Proving meta-properties about languages

Specifying and verifying concurrency

Relaxed memory models

FoundationsExplore non-serializable concurrency for rewriting

Models for K definitions



k: a rewriting approach to concurrent programming...

Documents