Specification verification and synthesis of concurrency control components
This presentation is the property of its rightful owner.
Sponsored Links
1 / 37

Specification, Verification, and Synthesis of Concurrency Control Components PowerPoint PPT Presentation


  • 88 Views
  • Uploaded on
  • Presentation posted in: General

Specification, Verification, and Synthesis of Concurrency Control Components. Tuba Yavuz-Kahveci Tevfik Bultan Department of Computer Science University of California, Santa Barbara {tuba,[email protected] Problem. Concurrent programming is difficult and error prone

Download Presentation

Specification, Verification, and Synthesis of Concurrency Control Components

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Specification verification and synthesis of concurrency control components

Specification, Verification, and Synthesis of Concurrency Control Components

Tuba Yavuz-Kahveci

Tevfik Bultan

Department of Computer Science

University of California, Santa Barbara

{tuba,[email protected]


Problem

Problem

  • Concurrent programming is difficult and error prone

    • Sequential programming: states of the variables

    • Concurrent programming: states of the variables & processes

  • When there is concurrency, testing is not enough

    • State space increases exponentially with the number of processes

  • We would like to guarantee certain properties of a concurrent system


Our approach

Our Approach

  • Specification of the concurrency component

    • Using Action Language

  • Automated verification

    • Using an infinite state model checker

      • Action Language Verifier

  • Automated code synthesis

    • Using a symbolic representation manipulator

      • Composite Symbolic Library


Tools for specification verification and synthesis of concurrent systems

Action Language

Verifier

Composite Symbolic

Library

Tools for Specification, Verification, and Synthesis of Concurrent Systems

Action Language

Specification of the

Concurrency Component

Action Language

Parser

Code Generator

Omega

Library

CUDD

Package

Verified code


Outline

Outline

  • Monitors

  • Specification of Monitors

    • Action Language

  • Verification

    • Action Language Verifier

  • Code Synthesis

  • Case Study: Airport Ground Traffic Control

    • Experiments

  • Related Work

  • Conclusions


Concurrency control with monitors

Concurrency Control with Monitors

  • A set of variables

    • Modeling shared resources

    • Cannot be accessed outside of the monitor

  • A set of procedures

    • Only one can be active at any time

      • Provided my the monitor semantics

  • Synchronization among concurrent processes

    • Using condition variables


Monitor basics

Monitor Basics

  • What happens if a process needs to wait until a condition becomes true?

    • Create a condition variable that corresponds to that condition

  • Each condition variable has a wait queue

    • A process waits for a condition in the wait queue of the corresponding condition variable

    • When a process updates the shared variables that may cause a condition to become true:

       it signals the processes in the wait queue of the corresponding condition variable


Monitors

Monitors

  • Challenges in monitor programming

    • Condition variables

    • Wait and signal operations

  • Why not use a single wait queue?

    • Inefficient: Every waiting process has to wake up when any of the shared variables are updated

  • Even with a few condition variables coordinating wait and signal operations can be difficult

    • Avoid deadlock

    • Avoid inefficiency due to unnecessary signaling


Java monitors

Java Monitors

  • A simplified implementation of Hoare monitors

    • No separate notion of condition variables

      • Can be simulated by objects

    • Each object associated with a mutual exclusion lock

      • synchronized(o) {…}

      • Synchronized methods

      • wait(), notify(), notifyAll()

    • Implementing monitors is complicated

  • To implement a monitor as a Java class

    • Shared resources must be implemented using private fields

    • All methods can change state of the fields only in synchronized blocks


Outline1

Outline

  • Monitors

  • Specification of Monitors

    • Action Language

  • Verification

    • Action Language Verifier

  • Code Synthesis

  • Case Study: Airport Ground Traffic Control

    • Experiments

  • Related Work

  • Conclusions


Action language

Action Language

  • A state based language

    • Actions correspond to state changes

  • States correspond to valuations of variables

    • Integer (possibly unbounded), boolean and enumerated variables

    • Parameterized constants

  • Transition relation is defined using actions

    • Atomic actions: Predicates on current and next state variables

    • Action composition: synchronous (&) or asynchronous (|)

  • Modular

    • Modules can have submodules

  • CTL properties

    • Invariant(p) : p always holds

    • Eventually(p) : p eventually holds


Readers writers

S :Cartesian product of

variable domains defines

the set of states

Readers Writers

I : Predicates defining

the initial states

module main()

integer nr;

boolean busy;

restrict: nr>=0;

initial:nr=0 and !busy;

module Reader()

booleanreading;

initial:!reading;

rEnter:!reading and !busy and

nr’=nr+1 and reading’;

rExit: reading and !reading’ and nr’=nr-1;

Reader:rEnter | rExit;

endmodule

module Writer()

...

endmodule

main:Reader() | Reader() | Writer() | Writer();

spec:invariant([busy => nr=0])

endmodule

R : Atomic actions of the

Reader

R : Transition relation of Reader defined as asynchronous composition of its atomic actions

R : Transition relation of main defined as asynchronous composition of two Reader and two Writer processes

P : Temporal property

of main module


What about arbitrary number of processes

What About Arbitrary Number of Processes?

  • Use counting abstraction

    • Create an integer variable for each local state of a process type

    • Each variable will count the number of processes in a particular state

  • Local states of the process types have to be finite

    • Specify only the process behavior that relates to the correctness of the monitor

    • Shared variables of the monitor can be unbounded

  • Counting abstraction can be automated


Readers writers monitor specification after counting abstraction

Readers-Writers Monitor Specification After Counting Abstraction

Parameterized constants representing the number of readers and number of writers

module main()

integer nr;

boolean busy;

parameterized integernumReader, numWriter;

restrict: nr>=0 and numReader>=0

and numWriter>=0;

initial: nr=0 and !busy;

module Reader()

integerreadingF, readingT;

initial:readingF=numReader

and readingT=0;

rEnter: readingF>0 and !busy

and nr’=nr+1 and

readingF’=readingF-1

and readingT’=readingT+1;

rExit: readingT>0 and nr’=nr-1 and

readingT’=readingT-1 and readingF’=readingF+1;

Reader: rEnter | rExit;

endmodule

...

main: Reader() | Writer();

spec: invariant([busy => nr=0])

endmodule

Variables for counting the number of processes in specific local states

Initialize initial local state counter by the relevant parameterized constant. Initialize other local states to 0

When local state changes, decrement current local state counter and increment next local state counter


Outline2

Outline

  • Monitors

  • Specification of Monitors

    • Action Language

  • Verification

    • Action Language Verifier

  • Code Synthesis

  • Case Study: Airport Ground Traffic Control

    • Experiments

  • Related Work

  • Conclusions


Action language verifier

Action Language Verifier

  • An infinite state symbolic model checker

  • Composite representation

    • uses a disjunctive representation to combine different symbolic representations

  • Computes fixpoints by manipulating formulas in composite representation

    • Heuristics to ensure convergence

      • Widening & collapsing

      • Loop closure

      • Approximate reachable states


Composite symbolic library class diagram

BoolSym

CompSym

IntSym

–representation: BDD

–representation: Polyhedra

–representation: list

of comAtom

+intersect()

+union()

+intersect()

+union()

+intersect()

+ union()

compAtom

–atom: *Symbolic

Composite Symbolic Library: Class Diagram

Symbolic

+intersect()

+union()

+complement()

+isSatisfiable()

+isSubset()

+bacwardImage()

+forwardImage()

CUDD Library

OMEGA Library


Outline3

Outline

  • Monitors

  • Specification of Monitors

    • Action Language

  • Verification

    • Action Language Verifier

  • Code Synthesis

  • Case Study: Airport Ground Traffic Control

    • Experiments

  • Related Work

  • Conclusions


Synthesizing the implementation of the monitor

Synthesizing the Implementation of the Monitor

  • Automated generation of code from the monitor specification

    • Generate a Java class

    • Make shared variables private variables

    • Use synchronization to restrict access

  • Is the generated code efficient?

    • Yes!

    • The condition variables can be synthesized automatically

    • There is no unnecessary thread notification


Na ve translation redundant signaling

Naïve Translation: Redundant Signaling

public class SetAB {

private boolean a.b;

public setAB() {

a = true;

b = true;

}

public synchronized SetA() {

while (!b)

try{ wait();} catch(…){..}

a = true;

b = false;

notifyAll();

}

public synchronized SetB() {

while (!a)

try{wait();} catch(…){…}

a = false;

b = true;

notifyAll();

}

}

Module main()

boolean a,b;

initial: a and b;

module SetA()

SetA: b and a’=true

and b’=false;

endmodule

module SetB()

SetB: a and a’=false

and b’=true;

endmodule

main: setA() | setB()

endmodule

Action Language Specification

Implementation in Java


Specific notification pattern

Specific Notification Pattern

class SetAB {

private boolean a.b;

private Object condA, condB;

private synchronized boolean Guard_SetA() {

if (b) { a = true; b = false; return true;}

else return false;

}

public void SetA() {

synchronized(condB) {

while (!Guard_SetA())

try{ condB.wait(); } catch(…) {…}

}

condA.notifyAll();

}

public void SetB() {

synchronized(condA) {

while (!Guard_SetB())

try{ condA.wait(); } catch(…) {..}

}

condB.notifyAll();

}

}

Module main()

boolean a,b;

initial: a and b;

module SetA()

SetA: b and a’=true

and b’=false;

endmodule

module SetB()

SetB: a and a’=false

and b’=true;

endmodule

main: setA() | setB()

endmodule

Action Language Specification

Implementation in Java


Algorithm for extracting synchronization information

Algorithm for Extracting Synchronization Information

for each action Ado

// Does A check any condition?

ifds(A) truethen

mark A as guarded

create condition variable condA

else

mark A as unguarded

for each action B s.t. A  Bdo

// Can A change the condition B waits on from false to true?

ifPOST( ds(B),EXP(A))  ds(B)  then

add condB to notification list of A


Readers writer example with specific notification pattern

Readers-Writer Example with Specific Notification Pattern

public class ReadersWriters{

private int nr;

private boolean busy;

private Object rEnterCond, wEnterCond;

private synchronized boolean Guard_rEnter() {

if (!busy) {

nr++;

return true;

}

else return false;

}

public void rEnter() {

synchronized(rEnterCond) {

while(!Guard_rEnter())

rEnterCond.wait();

}

public void rExit() {

synchronized(this) { nr--; }

synchronized(wEnterCond) { wEnterCond.notify(); }

}

...

}

All condition variables and

wait and signal operations are

generated automatically


Outline4

Outline

  • Monitors

  • Specification of Monitors

    • Action Language

  • Verification

    • Action Language Verifier

  • Code Synthesis

  • Case Study: Airport Ground Traffic Control

    • Experiments

  • Related Work

  • Conclusions


Airport ground traffic control

Airport Ground Traffic Control

  • [Zhong 97] Modeling of airport operations using an object oriented approach

  • A concurrent program simulating the airport ground traffic control

    • multiple planes

    • multiple runways and taxiways

  • Can be used by controllers as advisory input

  • Simulate behavior of each airplane with a thread

  • Use a monitor which keeps track of number of airplanes on each runway and each taxiway


Specification verification and synthesis of concurrency control components

A simplified model of Seattle Tacoma International Airport from [Zhong 97]


Airport ground traffic control monitor

Airport Ground Traffic Control Monitor

  • Action Language specification

    • Has 13 integer variables

    • Has 4 Boolean variables per arriving airplane process to keep the local state of each airplane

    • Has 2 Boolean variables per departing airplane process to keep the local state of each airplane

  • Automatically generated monitor class

    • Has 13 integer variables

    • Has 14 condition variables

    • Has 34 procedures


Experiments

A: Arriving Airplane

D: Departing Airplane

P: Arbitrary number of processes

Experiments


Related work demartini et al 99 corbett et al 00 havelund et al 00

Related Work: [Demartini et al., 99], [Corbett et al., 00], [Havelund et al., 00]

  • Extracting compact models from the implementation

    • Employing techniques such as slicing and abstraction

  • Automated verification of the model

    • Finite state model checker

    • Explicit state model checking techniques


Related work mizuno 99

Related Work: [Mizuno-99]

  • Given a concurrency problem and a global invariant

    • Provides a course-grain solution

      • <await B; S> or <S>

  • Translates the course-grain solution to a Java program

    • Using Specific Notification Pattern

      • Creates a separate condition variable cB for each guard B

      • When S may change B to true cB is signaled

    • Preserving the global invariant

  • Not automated


Related work deng et al 02

Related Work[Deng et al., 02]

  • Extends and automates Mizuno’s approach

  • Synthesizes the code from a global invariant:

    • A logic formula

      • Uses a decision procedure

    • A pattern specification

      • Bound, Exclusion, Resource, Barrier, Relay, and Group

  • Automatically verifies

    • synthesized synchronization code + functional application code

    • Uses a finite state model checker


Conclusions and future work

Conclusions and Future Work

  • We can automatically verify and synthesize nontrivial monitors in Java

  • Our tools can deal with boolean, enumerated and (unbounded) integer variables

  • What about recursive data types?

    • shape analysis

    • [SAS’02] Verification of Concurrent Linked Lists


Readers writers monitor in action language

Readers Writers Monitor in Action Language

modulemain()

integer nr;

boolean busy;

restrict: nr>=0;

initial: nr=0 and !busy;

module Reader()

boolean reading;

initial: !reading;

rEnter: !reading and !busy and

nr’=nr+1 and reading’;

rExit: reading and !reading’ and nr’=nr-1;

Reader: rEnter | rExit;

endmodule

module Writer()

boolean writing;

initial: !writing;

wEnter: !writing and nr=0 and !busy and

busy’ and writing’;

wExit: writing and !writing’ and !busy’;

Writer: wEnter | wExit;

endmodule

main: Reader() | Reader() | Writer() | Writer();

spec:invariant([busy => nr=0])

endmodule


Action language verifier1

Action Language Verifier

  • An infinite state symbolic model checker

  • Uses composite symbolic representation to encode a system defined by (S,I,R)

    • S: set of states, I: set if initial states, R: transition relation

  • Maps each variable type to a symbolic representation type

    • Maps boolean and enumerated types to BDD representation

    • Maps integer type to arithmetic constraint representation

  • Uses a disjunctive representation to combine symbolic representations

    • Each disjunct is a conjunction of formulas represented by different symbolic representations


Temporal properties fixpoints

Temporal Properties  Fixpoints

backwardImage

of p

Backward

fixpoint

Initial

states

• • •

p

initial states that

violate Invariant(p)

states that can reach p

i.e., states that violate Invariant(p)

Invariant(p)

Forward

fixpoint

Initial

states

• • •

p

reachable states

that violate p

forward image

of initial states

reachable states

of the system


Control logic

Control Logic

  • An airplane can land using 16R only if no airplane is using 16R at the moment

  • An airplane can takeoff using 16L only if no airplane is using 16L at the moment

  • An airplane taxiing on one of the exits C3-C8 can cross runway 16L only if no airplane is taking off at the moment

  • An airplane can start using 16L for taking off only if none of the crossing exits C3-C8 is occupied at the moment (arriving airplanes have higher priority)

  • Only one airplane can use a taxiway at a time


Synchronization among processes

wait

signal

Synchronization Among Processes

Executing Process

Ready Queue

Processk

Processk

Processi

Processk

Processm

condA

Waiting Queue

Processm

Processi


  • Login