Design for Verification for Concurrent and Distributed Software

1
Design for Verification for Concurrent and
Distributed Software

• Tevfik Bultan
• Department of Computer Science
• University of California, Santa Barbara

2
Joint Work with My Students

• Aysu Betin-Can
• Design for verification
• Tuba Yavuz-Kahveci, University of Florida,
  Gainesville
• Constantinos Bartzis, Carnegie Mellon University
• Action Language Verifier
• Infinite state model checking
• Xiang Fu, Georgia Southwestern State University
• Verification, realizability and synchronizability
  of web service conversations

3
Model Checking Software

• Scalability of software model checking depends on
• Extracting compact models from programs
• This typically requires a reverse engineering
  step based on user guidance and/or static
  analysis techniques to
• Rediscover some information about the software
  that may be known at design time
• Alternative approach Design for verification
• Structure software in ways that facilitate
  verification
• Document the design decisions that can be useful
  for verification
• Improve the scalability of verification using
  this information

4
A Design for Verification Approach

• We have been investigating a design for
  verification approach based on the following
  principles
• Using design patterns that facilitate automated
  verification
• Use of stateful, behavioral interfaces which
  isolate the behavior and enable modular
  verification
• An assume-guarantee style verification strategy
  which 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

5
Outline

• Design for verification for concurrent programs
• Checking correctness of synchronization
• Behavior verification using Action Language
  Verifier
• Interface verification using Java Path Finder and
  thread isolation
• Design for verification for web services
• Checking correctness of conversations
• Behavior verification using Spin and
  synchronizability analysis
• Interface verification using Java Path Finder and
  thread isolation

6
Concurrent Programming in Java

• Java uses a variant of monitor programming
• Synchronization using locks
• Each object has a lock
• synchronized(o) ...
• Coordination using condition variables
• Objects can be used as condition variables
• synchronized (condVar)
• while (!condExp) wait(condVar)
• ...
• notifyAll(condVar)

7
Dangers in Java Concurrency

• Nested locks
• synchronized m(other) other.m()
• run() o1.m(o2) run() o2.m(o1)
• Missed notification
• notify(condVar)
• Forgotten condition check
• if(!condExp) wait(condVar)
• Dependencies of condition variables can be
  complicated
• Conservative notification and condition check
• Inefficient
• Optimizing the notification and condition checks
• Error prone

8
Concurrency Controller Pattern

• A verifiable behavioral design pattern for
  concurrent programs
• Defines customized synchronization policies
• 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

9
Concurrency Controller Pattern Class Diagram
ThreadA
transition() assert(th.state)s
a() assert(contr.state)
int
10
Reader-Writer Controller
This helper class is provided, no need to rewrite
it

• class Action
• protected final Object owner
• private boolean GuardedExecute()
• boolean resultfalse
• for(int i0 iltgcV.size() i) try
• if(((GuardedCommand)gcV.get(i)).guard())
• ((GuardedCommand)gcV.get(i)).update()
• resulttrue break
• catch(Exception e)
• return result
• public void blocking()
• synchronized(owner)
• while(!GuardedExecute())
• tryowner.wait()
• catch (Exception e)
• owner.notifyAll()
• public boolean nonblocking()

• class RWController implements RWInterface
• int nR boolean busy
• final Action act_r_enter, act_r_exit
• final Action act_w_enter, act_w_exit
• RWController()
• ...
• gcs new Vector()
• gcs.add(new GuardedCommand()
• public boolean guard()
• return (nR 0 !busy)
• public void update()busy true
• )
• act_w_enter new Action(this,gcs)
• public void w_enter()
• act_w_enter.blocking()
• public boolean w_exit()
• return act_w_exit.nonblocking()
• public void r_enter()

11
Controller Interfaces

• A controller interface defines the acceptable
  call sequences for the threads that use the
  controller
• Interfaces are specified using finite state
  machines

• public class RWStateMachine implements
  RWInterface
• StateTable stateTable
• final static int idle0,reading1, writing2
• public RWStateMachine() ...
  stateTable.insert("w_enter",idle,writing)
• public void w_enter()
• stateTable.transition("w_enter")
• ...

reading
r_enter
r_exit
idle
w_exit
writing
w_enter
12
Optimizing Concurrency Controllers

• Possible inefficiencies
• After every action execution in the controller
  all the waiting threads are awakened
• The inner classes and the large number of method
  invocations may degrade the performance
• Solution Generate an optimized controller
  automatically using specific notification pattern
• Optimized controller
• Uses the specific notification pattern
• Does not have any inner classes
• Reduces the number of method invocations

13
Specific Notification Pattern

• public class ReadersWriters
• private int nr
• private boolean busy
• private Object r_enterCond, w_enterCond
• private synchronized boolean Guard_r_enter()
• if (!busy)
• nr
• return true
• else return false
• public void r_enter()
• synchronized(r_enterCond)
• while(!Guard_r_enter())
• r_enterCond.wait()
• public void r_exit()
• synchronized(this) nr--
• synchronized(w_enterCond)
  w_enterCond.notify()

All condition variables and wait and signal
operations are generated automatically
14
Design for Verification Approach
Behavior Specification in Action Language
Behavior Verification
Java Controller Class and Controller Interface
based on the Concurrency Controller Pattern
Action Language Verifier
Behavior Translator
Error Trace
Verified
Optimized Java Code
Notification-Optimizer
Data Stubs
Interface Verification
Java PathFinder
Thread Isolation
Program with Stubs
Concurrent Program
Verified
Error Trace
15
Modular Verification

• Behavior verification
• Verify the controller properties (e.g. safety,
  liveness) assuming that the user threads adhere
  to the controller interface
• Use a customized model checker
• Interface verification
• Check that each user thread obeys the interface
• A thread is correct with respect to an interface
  if all the call sequences generated by the thread
  can also be generated by the interface machine
• Use a software model checker with stubs
• Significant state space reduction because of stub
  substitution

16
Behavior Verification

• Verification tool Action Language Verifier
• Advantages Action Language Verifier can verify
  controllers
• with parameterized constants and unbounded
  variables
• for arbitrary number of user threads
• Behavior Verification Steps
• Automatically generate Action Language
  specifications from the controller class
• based on the actions and the interface of the
  controller
• Verify properties of concurrency controllers
  using Action Language Verifier
• Properties can be specified (by the user) at the
  code level or Action Language level

17
Action Language

• A state based language
• Actions correspond to state changes
• States correspond to valuations of variables
• boolean
• enumerated
• integer (possibly unbounded)
• heap variables (i.e., pointers)
• Parameterized constants
• specifications are verified for every possible
  value of the constant

18
Action Language

• Transition relation is defined using actions
• Atomic actions Predicates on current and next
  state variables
• Action composition
• asynchronous () or synchronous ()
• Modular
• Modules can have submodules
• A module is defined as asynchronous and/or
  synchronous compositions of its actions and
  submodules

19
Readers Writers Controller in Action Language

• module main()
• integer nr
• boolean busy
• restrict nrgt0
• initial nr0 and !busy
• module ReaderWriter()
• enumerated state idle, reading, writing
• initial states0
• 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

20
Action Language Verifier
Action Language Specification
Action Language Parser
Composite Symbolic Library
Model Checker
Omega Library
CUDD Package
MONA
Counter-example
Verified
Presburger Arithmetic Manipulator
BDD Manipulator
Automata Manipulator
Not sure
21
Composite Symbolic Library Class Diagram
Symbolic

• intersect()
• union()
• complement()
• isSatisfiable()
• isSubset()
• pre()
• post()

CUDD Library
OMEGA Library
22
Composite Symbolic Library with Extensions
Symbolic

• union()
• isSatisfiable()
• isSubset()
• forwardImage()

HeapSym
representation list of ShapeGraph

• union()

OMEGA
CUDD
MONA
23
Verification for Arbitrary Number of Threads

• Counting abstraction
• Create an integer variable for each interface
  state
• Each variable counts the number of threads in a
  particular interface state
• Automatically generate updates and guards for
  these variables based on the interface
  specification
• Counting abstraction is automated

24
Readers-Writers After Counting Abstraction

• module main()
• integer nr
• boolean busy
• parameterized integer numReaderWriter
• restrict nrgt0 and numReaderWritergt1
• initial nr0 and !busy
• module ReaderWriter()
• integer idle, reading, writing
• initial idlenumReaderWriter
• r_enter idlegt0 and !busy and nrnr1
• and idleidle-1 and
  readingreading1
• r_exit readinggt0 and nrnr-1 and
  readingreading-1
• and idleidle1
• w_enter idlegt0 and !busy and nr0 and busy
• and idleidle-1 and
  writingwriting1
• w_exit writinggt0 and !busy and
  writingwriting-1
• and idleidle1

25
Verification of Readers-Writer Controller
Integers Booleans Cons. Time (secs.) Ver. Time (secs.) Memory (Mbytes)
RW-4 1 5 0.04 0.01 6.6
RW-8 1 9 0.08 0.01 7
RW-16 1 17 0.19 0.02 8
RW-32 1 33 0.53 0.03 10.8
RW-64 1 65 1.71 0.06 20.6
RW-P 7 1 0.05 0.01 9.1
SUN ULTRA 10 (768 Mbyte main memory)
26
Example Airport Ground Traffic Control Simulation
A simplified model of Seattle Tacoma
International Airport from Zhong 97
27
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

28
Controller Interface
leave
Airport Ground Traffic Control
29
Airport Ground Traffic Control

• Action Language specification of the controller
• Has 13 integer variables
• Has 6 Boolean variables per airplane process to
  keep the local state of each airplane
• 20 actions
• Optimized Java concurrency controller class
• Has 13 integer variables
• Has 14 condition variables
• Has 34 methods

30
Experiments
A Arriving Airplane D Departing Airplane P
Arbitrary number of threads
Processes Construction(sec) Verify-P1(sec) Verify-P2(sec) Verify-P3(sec)
2 0.81 0.42 0.28 0.69
4 1.50 0.78 0.50 1.13
8 3.03 1.53 0.99 2.22
16 6.86 3.02 2.03 5.07
2A,PD 1.02 0.64 0.43 0.83
4A,PD 1.94 1.19 0.81 1.39
8A,PD 3.95 2.28 1.54 2.59
16A,PD 8.74 4.6 3.15 5.35
PA,2D 1.67 1.31 0.88 3.94
PA,4D 3.15 2.42 1.71 5.09
PA,8D 6.40 4.64 3.32 7.35
PA,16D 13.66 9.21 7.02 12.01
PA,PD 2.65 0.99 0.57 0.43
31
Interface Verification

• Verification tool Java PathFinder (JPF)
• Advantages JPF Can check arbitrary thread
  implementations
• Interface Verification Steps
• Isolate each thread implementation using stubs
  generated from the controller interfaces
• Check each thread implementation separetly for
  interface violations using JPF

32
Interface Verification

• Replace the instances of the controllers with the
  corresponding stubs
• i.e., the interface state machines
• Replace the shared data protected by these
  controllers with data stubs
• Interface verification will check if a user
  thread accesses shared data only when it is in a
  correct interface state
• Significant reduction in state space

33
Thread Isolation

• Thread isolation assumption
• Threads only interact through the controllers and
  the shared data that are protected by these
  controllers
• Close the environment of a thread
• User input (user interfaces)
• RMI interaction
• Network communication
• File I/O
• Check each thread implementation separately

34
Case Study Concurrent Editor

• 2800 lines of Java code with
• 17 class files
• 5 controller classes
• 7 Java interfaces
• Implemented using concurrency controller pattern
  without writing any Java synchronization
  operations

35
Concurrent Editor
36
(No Transcript)
37
Concurrent Editor Interface Verification

• Handling RMI methods isolation
• Drivers simulating incoming calls to a node
• Stubs simulating outgoing calls to another node
• Handling GUI interactions
• Driver simulates the user interactions
• Threads in the Server
• Threads serving RMI requests
• Threads in a Client other than main
• Event Thread capturing GUI events
• Worker Thread per paragraph
• Event thread creates Worker threads
• Less abstraction in data stubs of the Event
  thread

38
Verification Results
Behavior Verification with ALV
Interface Verification with JPF
Controllers T (sec) M (MB)
Mutex 0.01 6.00
Bounded Buffer 2.05 6.47
Barrier 0.01 0.5
Reader Writer 0.42 6.94
Threads T (sec) M (MB)
Server RMI 185.85 67.14
Client RMI 229.18 127.04
Event 1636.62 139.48
Worker 19.47 5.36

• Errors discovered (interface violation errors)
• Caused by not calling the correct controller
  method before accessing the shared data
• Violation of the controller call sequence because
  of the incorrectly handled exception blocks

39
Comments

• We applied the same approach to a larger system
  (TSAFE) and used fault injection to test the
  effectiveness of our approach
• We can find all the controller errors (depending
  on the controller properties)
• We can find all interface errors (other than the
  convoluted ones)
• Challenges
• Thread isolation
• Environment generation
• Scalability of interface verification
• Completeness of controller properties

40
Outline

• Design for verification for concurrent programs
• Checking correctness of synchronization
• Behavior verification using Action Language
  Verifier
• Interface verification using Java Path Finder
• Design for verification for web services
• Checking correctness of conversations
• Behavior verification using Spin and
  synchronizability analysis
• Interface verification using Java Path Finder

41
Characteristics of Web Services

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

WSCDL
Interaction
BPEL4WS
Composition
Service
WSDL
Implementation Platforms
Microsoft .Net, Sun J2EE
SOAP
Message
XML Schema
Type
XML
Data
Web Service Standards
42
An Example Stock Analysis Service

• Three peers Investor (Inv), Stock Broker (SB),
  and Research Department (RD)
• Inv initiates the stock analysis service by
  sending a register message to the SB
• The SB may accept or reject the registration
• If the registration is accepted, the SB sends an
  analysis request to the RD
• RD sends the results of the analysis directly to
  the Inv as a report
• After receiving a report the Inv can either send
  an ack to the SB or cancel the service
• Then, the SB either sends the bill for the
  services to the Inv, or continues the service
  with another analysis request

43
An Example Stock Analysis Service (SAS)

• SAS is a composite web service
• a finite set of peers Inv, SB, RD
• and a finite set of message classes register,
  ack, cancel, accept, reject, bill, request,
  terminate, report

register ack, cancel
Investor (Inv)
Stock Broker (SB)
accept, reject, bill
report
request, terminate
Research Dept. (RD)
44
Communication Model

• We assume that the messages among the peers are
  exchanged using reliable and asynchronous
  messaging
• FIFO and unbounded message queues

Stock Broker (SB)
Research Dept. (RD)
req
req

• This model is similar to industry efforts such as
  
• JMS (Java Message Service)
• MSMQ (Microsoft Message Queuing Service)

45
Composite Web Service Execution
Investor
Stock Broker Firm
?register
!register
?reject
!reject
!accept
?accept
!request
!ack
acc
rep
bil
?report
?ack
reg
ack
!bill
?bill
?cancel
!cancel
?bill
!bill
!terminate
Research Dept.
!report
?request
req
ter
?terminate
46
Conversations

• Assume that a virtual watcher records the
  messages as they are sent

Investor (Inv)
Stock Broker (SB)
Watcher
rep
acc
bil
reg
ack
req
ter
Research Dept. (RD)

• A conversation is a sequence of messages the
  watcher sees during an execution

47
Conversations and Asynchronous Communication

• We know that analyzing conversations of composite
  web services is difficult due to asynchronous
  communication
• Model checking for conversation properties is
  undecidable even for finite state peers
• The question is
• Can we identify the composite web services where
  asynchronous communication does not create a
  problem?

48
Synchronizability Analysis

• 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 its properties about its conversations
  using synchronous communication semantics
• For finite state peers this is a finite state
  model checking problem

49
Synchronizability Conditions

• Sufficient conditions for realizability (no
  message content)
• Synchronous compatible
• When the peers are composed synchronously, there
  should not be a state where a peer is ready to
  send a message while the corresponding receiver
  is not ready to receive
• Autonomous
• At any state, each peer should be able to do only
  one of the following send, receive or terminate
• (a peer can still choose among multiple messages)

50
Are These Conditions Too Restrictive?
Problem Set Problem Set Size Size Size Synchronizable?
Source Name msg states trans.
ISSTA04 SAS 9 12 15 yes
IBM Conv. Support Project CvSetup 4 4 4 yes
IBM Conv. Support Project MetaConv 4 4 6 no
IBM Conv. Support Project Chat 2 4 5 yes
IBM Conv. Support Project Buy 5 5 6 yes
IBM Conv. Support Project Haggle 8 5 8 no
IBM Conv. Support Project AMAB 8 10 15 yes
BPEL spec shipping 2 3 3 yes
BPEL spec Loan 6 6 6 yes
BPEL spec Auction 9 9 10 yes
Collaxa. com StarLoan 6 7 7 yes
Collaxa. com Cauction 5 7 6 yes
51
Design for Verification Approach
Behavior Specification In Promela
Behavior Verification
Java Controller Class and Controller Interface
based on the Peer Controller Pattern
Behavior Translator
Spin
Error Trace
Verified
Synchronizability Analysis
Interface Verification
Java PathFinder
Thread Isolation
Distributed Program
Program with Stubs
Verified
Error Trace
52
Peer Controller Pattern

• Eases the development of web services
• Uses Java API for XML messaging (JAXM)
• Asynchronous communication among peers
• Supported by a modular verification technique
• Behavior Verification Checks properties of
  conversations of a web service composed of
  multiple peers
• assuming that peers behave according to their
  interfaces
• Interface Verification Checks if each peer
  behaves according to its interface

53
Peer Controller Pattern
54
Modular Verification

• Behavior Verification
• Uses synchronizability analysis
• Uses Spin model checker
• Spin model checker supports asynchronous
  communication
• Automated translation to Promela
• Verifies properties of conversations
• Interface Verification
• Isolated check of individual peer implementations
  
• Uses program checker JPF

55
Behavior Verification

• Spin is a finite state model checker
• We have to bound the channel sizes, session
  numbers, message types
• Synchronizability analysis
• Enables us to verify web services efficiently by
  replacing communication channels with channels of
  size 0 (i.e., synchronous communication)
• The verification results hold for unbounded
  channels

56
Interface Verification

• If the call sequence to the Communicator class is
  accepted by the automata specifying the
  interface, then the peer implementation conforms
  to the behavior in the contract
• Interface Verification
• CommunicationController is replaced with
  CommunicatorInterface
• Drivers simulating other peers are automatically
  generated
• State Space reduction
• Usage of stubs
• Each session is independent
• just need to check each peer for one session

57
Examples

• We used this approach to implement several simple
  web services
• Travel agency
• Loan approver
• Product ordering
• Performance of both interface and behavior
  verification were reasonable

58
Interface Verification
Interface Verification with JPF for Loan Approver
Threads T (sec) M (MB)
Customer 8.86 3.84
Loan Approver 9.65 4.7
Risk Assesor 8.15 3.64
59
Behavior Verification

• Sample Property Whenever a request with a small
  amount is sent, eventually an approval message
  accepting the loan request will be sent.
• Loan Approval system has 154 reachable states
• because each queue length never exceeds 1.
• Behavior verification used lt1 sec and 1.49 MB
• SPIN requires restricted domains
• Have to bound the channel sizes ? bounded message
  queues
• Problem No guarantee these results will hold for
  other queue sizes

60
Another Example

• SPIN runs out of memory for message queue size
  15!
• Absence of error for queue size 15 does not
  ensure correctness
• Reachable state space is infinite
• Issue is not only unbounded queues, but also
  efficiency
• Solution We use synchronizability analysis
• The example above and Loan Approver are both
  synchronizable

61
Comments

• We were able to use our design for verification
  approach based on design patterns and behavioral
  interfaces in different domains
• Use of domain specific behavior verification
  techniques has been very effective
• Interface verification is challenging
• Model checking research resulted in various
  verification techniques and tools which can be
  customized for specific classes of software
  systems
• Automated verification techniques can scale to
  realistic software systems using design for
  verification approach

62
References

• Design for Verification
• Betin-Can, Bultan SoftMC03, ASE04, WWW05,
  ICWS05
• Action Language Verifier
• Bultan ICSE 00, Bultan, Yavuz-Kahveci ASE 01,
  Yavuz-Kahveci, Bar, Bultan CAV 2005
• Composite Symbolic Library
• Yavuz-Kahveci, Tuncer, Bultan TACAS01,
  Yavuz-Kahveci, Bultan FroCos 02, STTT 03
• Realizability and Synchronizability of Web
  Services
• Bultan, Fu, Hull, Su WWW03, Fu, Bultan, Su
  CIAA03, TCS04, WWW04, ICWS04
• Infinite State Model Checking
• Bar Bultan CIAA02, IJFCS03, CAV03,CAV04

63
Related Work Design for Verification

• Design for Verification
• Magee, Kramer 99
• uses LTSA model checker for verification of
  finite state models of Java concurrent programs
• Sharygina, Browne, Kurshan FASE 01
• presents design rules for object-oriented design
  models to facilitate verification
• Mehlitz, Penix Workshop on Component-Based Soft.
  Eng. 03
• promotes using design patterns and exploiting
  their properties in verification
• Design patterns for concurrency
• Schmidt, Stal, Rohmert, Buschmann 00, Lea 99,
  Grand 02
• Environment extraction/generation
• Godefroid, Colby, Jagadeesan PLDI 98, Tkachuk,
  Dwyer ASE 03, Tkachuk, Dwyer, Pasareanu
  ESEC/FSE 03

64
Related Work Model Checking Programs

• Verisoft from Bell Labs Godefroid POPL 97
• C programs, handles concurrency, bounded search,
  bounded recursion, stateless search
• Java Path Finder (JPF) at NASA Ames Havelund,
  Visser
• Explicit state model checking for Java programs,
  bounded search, bounded recursion, handles
  concurrency
• SLAM project at Microsoft Research
• Ball, Rajamani et al. SPIN 00, PLDI 01
• Symbolic model checking for C programs, unbounded
  recursion, no concurrency
• Uses predicate abstraction Saidi, Graf 97 and
  BDDs
• BANDERA A tool for extracting finite state
  models from programs Dwyer, Hatcliff et al ICSE
  00, 01
• Modular model checking of software components
• Chaki, Clarke, Groce, Jha, Veith ICSE 03

65
Related Work Web Services

• Conversation specification
• IBM Conversation support project
  http//www.research.ibm.com/convsupport/
• Conversation support for business process
  integration Hanson, Nandi, Kumaran EDOCC02
• Orchestrating computations on the world-wide web
  Choi, Garg, Rai, Misram, Vin EuroPar02
• Realizability problem
• Realizability of Message Sequence Charts (MSC)
  Alur, Etassami, Yannakakis ICSE00, ICALP01

66
Related Work Web Services

• Verification of web services
• Simulation, verification, composition of web
  services using a Petri net model Narayanan,
  McIlraith WWW02
• BPEL verification using a process algebra model
  and Concurrency Workbench Koshkina, van Breugel
  TAV-WEB03
• Using MSC to model BPEL web services which are
  translated to labeled transition systems and
  verified using model checking Foster, Uchitel,
  Magee, Kramer ASE03
• Model checking Web Service Flow Language
  specifications using Spin Nakajima ICWE04
• Conformance checking for asynchronously
  communicating processes
• Rajamani, Rehof CAV02
• conformance checking between specification model
  and a model extracted from the implementation