Developing Verifiable Concurrent Software Tevfik Bultan Department of Computer Science University of California, Santa Barbara

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)

Verification Tools, Concurrency Problems Action Language Verifier Verification of Synchronization in Concurrent Programs Synchronizability Analysis Analyzing Web Service Interactions Design for Verification uses enables

Read-Write Lock in Action Language module main() integer nr; boolean busy; restrict: nr>=0; initial: nr=0 and !busy; module ReaderWriter() enumerated state {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 S : Cartesian product of variable domains defines variable domains defines the set of states the set of states I : Predicates defining the initial states the initial states R : Atomic actions of a single process a single process R : Transition relation of a process, defined as process, defined as asynchronous asynchronous composition of its composition of its atomic actions atomic actions R : Transition relation of main, defined as asynchronous composition of three processes

A Java Read-Write Lock Implementation 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 errors if ((totalReadLocksGiven == 0) && (!writeLockIssued)) { System.out.println(" Error: Invalid call to release the lock"); return; } if (writeLockIssued) writeLockIssued = false; else totalReadLocksGiven--; lockObj.notifyAll(); } } } Where are the guarded commands? How do we translate this to Action Language? Action Language Verifier Verification of Synchronization in Java Programs

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

A Design for Verification Approach We have been investigating a design for verification approach based on the following principles: 1.Use of design patterns that facilitate automated verification 2.Use of stateful, behavioral interfaces which isolate the behavior and enable modular verification 3.An assume-guarantee style modular verification strategy that separates verification of the behavior from the verification of the conformance to the interface specifications 4.A general model checking technique for interface verification 5.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

Interface Machine Thread 1Thread 2Thread n Thread 1 Controller Shared Data Interface Machine Thread 2 Interface Machine Thread n Thread Modular Interface Verification Concurrent Program Controller Behavior Modular Behavior Verification Modular Design / Modular Verification Interface

Concurrent Program Controller Classes Thread Classes Controller Interface Machine Controller Behavior Machine Java Path Finder Action Language Verifier Thread Isolation Thread Class Counting Abstraction Interface Verification Behavior Verification Verification Framework

Outline Action Language Verifier Verification of Synchronization in Concurrent Programs Synchronizability Analysis Analyzing Web Service Interactions Design for Verification uses enables

Web Services Loosely coupled, interaction through standardized interfaces Standardized data transmission via XML Asynchronous messaging Platform independent (.NET, J2EE) Data Type Service Composition Message WSBPEL Web Service Standards Implementation Platforms Microsoft.Net, Sun J2EE WSDL SOAP XML Schema XML WSCDL Interaction

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?

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

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

Design for Verification Approach Use the same principles: 1.Use of design patterns that facilitate automated verification 2.Use of stateful, behavioral interfaces which isolate the behavior and enable modular verification 3.An assume-guarantee style modular verification strategy that separates verification of the behavior from the verification of the conformance to the interface specifications 4.A general model checking technique for interface verification 5.Domain specific and specialized verification techniques for behavior verification

Interface Machine Peer 1 Peer 2Peer n Peer 1 Interface Machine Peer 2 Interface Machine Peer n Peer Modular Interface Verification Composite Service Conversation Behavior Modular Conversation Verification Modular Design / Modular Verification interface

Composite Service Peer State Machine Promela Java Path Finder Spin Peer Code Interface Verification Verification Framework Thread Peer State Machines WSAT Synchronizability Analysis Conversation Verification Promela Translation

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!

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

THE END