Developing Verifiable Concurrent Software

1
Developing Verifiable Concurrent Software

• Tevfik Bultan
• Department of Computer Science
• University of California, Santa Barbara
• bultan_at_cs.ucsb.edu
• http//www.cs.ucsb.edu/bultan

2
Joint Work with My Students

• Design for verification
• Aysu Betin-Can (PhD 2005)
• Verification of Service Interactions
• Xiang Fu (PhD 2004)
• Action Language Verifier
• Tuba Yavuz-Kahveci (PhD 2004)
• Constantinos Bartzis (PhD 2004)
• Interface Grammars
• Graham Hughes (PhD candidate)

3
Verification Tools, Concurrency Problems
Action Language Verifier
Synchronizability Analysis
Design for Verification
enables
enables
uses
uses
Verification of Synchronization in
Concurrent Programs
Analyzing Web Service Interactions
4
Read-Write Lock in Action Language
S Cartesian product of variable domains
defines the set of states

• module main()
• integer nr
• boolean busy
• restrict nrgt0
• initial nr0 and !busy
• module ReaderWriter()
• enumerated state idle, reading, writing
• initial stateidle
• r_enter stateidle and !busy and nrnr1
  and statereading
• r_exit statereading and nrnr-1 and
  stateidle
• w_enter stateidle and !busy and nr0 busy
  and statewriting
• w_exit statewriting and !busy and
  stateidle

I Predicates defining the initial states
R Atomic actions of a single process
R Transition relation of a process,
defined as asynchronous
composition of its atomic actions
R Transition relation of main, defined as
asynchronous composition of three processes
5
A Java Read-Write Lock Implementation
Where are the guarded commands?

• class ReadWriteLock   private Object lockObj  
  private int totalReadLocksGiven  private boolean
   writeLockIssued  private int threadsWaitingForW
  riteLock  public ReadWriteLock()     lockObj 
   new Object()    writeLockIssued  false    
    public void getReadLock()     synchronized (lo
  ckObj)       while ((writeLockIssued)  (thread
  sWaitingForWriteLock ! 0))         try       
      lockObj.wait()         catch (InterruptedEx
  ception e)                     totalReadLock
  sGiven        public void getWriteLock() 
      synchronized (lockObj)       threadsWaiting
  ForWriteLock      while ((totalReadLocksGiven
   ! 0)  (writeLockIssued))         try      
       lockObj.wait()         catch (InterruptedE
  xception e)           //                   
   threadsWaitingForWriteLock--      writeLockIssu
  ed  true        public void done()     sy
  nchronized (lockObj)       //check for errors 
       if ((totalReadLocksGiven  0)  (!writeLock
  Issued))         System.out.println(" Error Inv
  alid call to release the lock")        return 
             if (writeLockIssued)        writeLoc
  kIssued  false      else        totalReadLocks
  Given--      lockObj.notifyAll()      
  

How do we translate this to Action Language?
Action Language Verifier
Verification of Synchronization in Java Programs
6
Design for Verification

• Abstraction and modularity are key both for
  successful designs and scalable verification
  techniques
• The question is
• How can modularity and abstraction at the design
  level be better integrated with the verification
  techniques which depend on these principles?
• Our approach
• Structure software in ways that facilitate
  verification
• Document the design decisions that can be useful
  for verification
• Improve the applicability and scalability of
  verification using this information

7
A Design for Verification Approach

• We have been investigating a design for
  verification approach based on the following
  principles
• Use of design patterns that facilitate automated
  verification
• Use of stateful, behavioral interfaces which
  isolate the behavior and enable modular
  verification
• An assume-guarantee style modular verification
  strategy that separates verification of the
  behavior from the verification of the conformance
  to the interface specifications
• A general model checking technique for interface
  verification
• Domain specific and specialized verification
  techniques for behavior verification

• Avoids usage of error-prone Java synchronization
  primitives
• synchronize, wait, notify
• Separates controller behavior from the threads
  that use the controller
• Supports a modular verification approach
  which exploits this modularity
• for scalable verification

8
Modular Design / Modular Verification
Thread Modular Interface Verification
Concurrent Program
Thread 1
Thread 2
Thread n
Thread 1
Thread 2
Thread n
Interface Machine
Interface Machine
Interface Machine
Interface
Controller
Modular Behavior Verification
Shared Data
Controller Behavior
9
Verification Framework
Behavior Verification
Action Language Verifier
Controller Behavior Machine
Controller Classes
Counting Abstraction
Concurrent Program
Controller Interface Machine
Interface Verification
Java Path Finder
Thread
Thread Isolation
Thread
Thread Class
Thread Classes
10
Outline
Action Language Verifier
Synchronizability Analysis
Design for Verification
enables
enables
uses
uses
Verification of Synchronization in
Concurrent Programs
Analyzing Web Service Interactions
11
Web Services

• Loosely coupled, interaction through standardized
  interfaces
• Standardized data transmission via XML
• Asynchronous messaging
• Platform independent (.NET, J2EE)

WSCDL
Interaction
WSBPEL
Composition
Service
WSDL
Implementation Platforms
Microsoft .Net, Sun J2EE
SOAP
Message
XML Schema
Type
XML
Data
Web Service Standards
12
A Model for Composite Web Services

• A composite web service consists of
• a finite set of peers and a finite set of
  messages
• We assume that the messages among the peers are
  exchanged using reliable and asynchronous
  messaging
• FIFO and unbounded message queues
• A conversation is the global sequence of messages
  exchanged among the peers participating to a
  composite service
• Model checking problem Given an LTL property,
  does the conversation set satisfy the property?

13
Synchronizability Analysis

• We know that analyzing conversations of composite
  web services is difficult due to asynchronous
  communication
• Can we identify the composite web services where
  asynchronous communication does not create a
  problem?
• A composite web service is synchronizable, if its
  conversation set does not change when
  asynchronous communication is replaced with
  synchronous communication
• If a composite web service is synchronizable we
  can check properties about its conversations
  using synchronous communication semantics
• We built a tool called Web Service Analysis Tool
  (WSAT), which checks sufficient conditions for
  synchronizability
• Requires each peer participating to the composite
  service to be specified as a state machine

14
Checking Service Implementations

• Web service implementations are written using
  programming languages such as Java, C, etc.
• Synchronizability analysis works on state machine
  models
• How do we generate the state machines from the
  Java code?

Synchronizability Analysis
Checking Service Implementations
15
Design for Verification Approach

• Use the same principles
• Use of design patterns that facilitate automated
  verification
• Use of stateful, behavioral interfaces which
  isolate the behavior and enable modular
  verification
• An assume-guarantee style modular verification
  strategy that separates verification of the
  behavior from the verification of the conformance
  to the interface specifications
• A general model checking technique for interface
  verification
• Domain specific and specialized verification
  techniques for behavior verification

16
Modular Design / Modular Verification
Peer Modular Interface Verification
Composite Service
Peer 1
Peer 2
Peer n
Peer 1
Peer 2
Peer n
Interface Machine
Interface Machine
Interface Machine
interface
interface
interface
Modular Conversation Verification
Conversation Behavior
17
Verification Framework
Thread
Promela
WSAT
Thread
Peer State Machines
Promela Translation
Synchronizability Analysis
Conversation Verification
Composite Service
Spin
Peer State Machine
Interface Verification
Java Path Finder
Peer Code
18
Conclusions

• Once the behavior is isolated (using concurrency
  controller or peer controller patterns) behavior
  verification was quite efficient
• Use of domain specific behavior verification
  techniques has been very effective
• Model checking research resulted in numerous
  verification techniques and tools which can be
  customized for specific classes of software
  systems
• Interface verification (which is less
  specialized) was very hard
• It is necessary to find effective behavioral
  interface specification and verification
  techniques
• Check out our recent work on interface grammars!

19
Conclusions

• We were able to use our design for verification
  approach based on design patterns and behavioral
  interfaces in different domains
• Automated verification techniques can scale to
  realistic software systems using a design for
  verification approach

20
THE END