Developing Verifiable Concurrent Software

1. Developing Verifiable Concurrent Software Tevfik Bultan Department of Computer Science University of California, Santa Barbara bultan@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. module main() integernr; booleanbusy; restrict: nr>=0; initial: nr=0 and !busy; module ReaderWriter() enumeratedstate {idle, reading, writing}; initial: state=idle; r_enter: state=idle and !busy and nr’=nr+1 and state’=reading; r_exit: state=reading and nr’=nr-1 and state’=idle; w_enter: state=idle and !busy and nr=0 busy’ and state’=writing; w_exit: state=writing and !busy’ and state’=idle; ReaderWriter: r_enter | r_exit | w_enter | w_exit; endmodule main: ReaderWriter() | ReaderWriter() | ReaderWriter(); spec: invariant(busy => nr=0) spec: invariant(busy => eventually(!busy)) endmodule Read-Write Lock in Action Language S : Cartesian product of variable domains defines the set of states 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 threadsWaitingForWriteLock;public ReadWriteLock() {    lockObj = new Object();    writeLockIssued = false;  }  public void getReadLock() {synchronized (lockObj) {while ((writeLockIssued) || (threadsWaitingForWriteLock != 0)) {try {          lockObj.wait();        } catch (InterruptedException e) {        }      }      totalReadLocksGiven++;    }  }public void getWriteLock() {synchronized (lockObj) {      threadsWaitingForWriteLock++;while ((totalReadLocksGiven != 0) || (writeLockIssued)) {try {          lockObj.wait();        } catch (InterruptedException e) {          //        }      }      threadsWaitingForWriteLock--;      writeLockIssued = true;    }  }public void done() {synchronized (lockObj) {      //check for errorsif ((totalReadLocksGiven == 0) && (!writeLockIssued)) {        System.out.println(" Error: Invalid call to release the lock");return;      }if (writeLockIssued)        writeLockIssued = false;else        totalReadLocksGiven--;      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 issynchronizable, 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