Synchronizability for Verification of
Asynchronously Communicating
Systems
Samik Basu
Iowa State University
Tevfik Bultan
University of California at Santa Barbara
Meriem Ouederni
University of Malaga
Asynchronously Communicating Systems
• Message-based asynchronous communication has been adopted in
many domains:
– Web service composition
• Interacting component services
• Java API for XML Messaging (JAXM)
– Distributed programming
• Interacting distributed programs
• Erlang
– System programming
• Interacting processes
• Singularity OS, Go programming language
Asynchronous Messaging
• Sender does not have to wait for the receiver
– Message is inserted to a message queue
– Messaging platform guarantees the delivery of the message
• Why support asynchronous messaging?
– Otherwise the sender has to block and wait for the receiver
– Sender may not need any data to be returned
– If the sender needs some data to be returned, it should only wait
when it needs to use that data
– Asynchronous messaging can alleviate the latency of message
transmission
– Asynchronous messaging can prevent sender from blocking if the
receiver service is temporarily unavailable
• Rather then creating a thread to handle the send, use
asynchronous messaging
Objective & Challenge
• Automatic verification of desired properties of asynchronous systems
• Asynchronous communication is hard to analyze
– Systems can have infinite-state spaces due to message queues
– Asynchronously communicating finite state machines can simulate
Turing Machines
– In general, automated verification of asynchronously
communicating finite state machines is undecidable
Motivation: Singularity OS
• Experimental OS developed by Microsoft Research to explore new
ideas for operating system design
• Key design principles:
– Dependability
– Security
• Key architectural decision:
– Implement a sealed process system
• Software Isolated Processes (SIPs)
– Closed code space (no dynamic code loading or code generation)
– Closed object space (no shared memory)
• Inter-process communication occurs via asynchronous message
passing over channels
Singularity Channels
• Channels allow 2-Party asynchronous communication via FIFO
message queues
– Sends are non blocking
– Receives block until a message is at the head of a receive queue
• Each channel has exactly two endpoints
– Type exposed for each endpoint (Exp and Imp)
– Each endpoint owned by at most one process at any time
• Owner of Exp referred to as Server
• Owner of Imp referred to as Client
Channel Contracts
• Written in Sing #
• Contracts specify two things:
1. The messages that may be sent
over a channel
• out message are sent from the
Server endpoint to the Client
endpoint (SC)
• in messages are sent from the
Client endpoint to the Server
endpoint (CS)
public contract KeyboardDeviceContract {
out message AckKey( uint key );
out message NakKey();
out message Success();
in message GetKey();
in message PollKey();
state Start {
Success! -> Ready;
}
state Ready {
GetKey? -> Waiting;
PollKey? -> (AckKey! or NakKey!)
-> Ready;
}
2. The set of allowed message
sequences
• out message marked with !
• in messages marked with ?
state Waiting {
AckKey! -> Ready;
NakKey! -> Ready;
}
}
Channel Contracts
• A contract specifies a finite state machine
• Each message causes a transition from one state to another state
public contract KeyboardDeviceContract {
KeyboardDeviceContract
out message AckKey( uint key );
out message NakKey();
out message Success();
in message GetKey();
in message PollKey();
Start
SC:AckKey
SC:Success
Ready
SC:NakKey
state Start {
Implicit
Success! -> Ready;
State
}
CS:PollKey
CS:GetKey
Waiting
SC:AckKey
Ready$0
SC:AckKey
state Ready {
GetKey? -> Waiting;
PollKey? -> (AckKey! or NakKey!)
-> Ready;
}
state Waiting {
AckKey! -> Ready;
NakKey! -> Ready;
}
}
Singularity Channel Contract Verification
• Singularity compiler automatically checks compliance of client and
server processes to the specified contract
• Claim from Singularity documentation:
– "clients and servers that have been verified separately against the
same contract C are guaranteed not to deadlock when allowed to
communicate according to C.“
• This claim is wrong!
Bad Things Can Happen: The TpmContract
Server
ReadyState$0
Send?
Server
Receive Queue
AckStartSend!
SendComplete!
TpmStatus!
GetTpmStatus
Send
ReadyState
IO_RUNNING
GetTpmStatus?
GetTpmStatus?
ReadyState$1
IO_RUNNING$0
TpmStatus!
Stuck!
Client
ReadyState$0
Send!
Client
Receive Queue
AckStartSend?
SendComplete?
SendComplete
AckStartSend
ReadyState
IO_RUNNING
GetTpmStatus!
GetTpmStatus!
ReadyState$1
IO_RUNNING$0
TpmStatus?
TpmStatus
TpmStatus?
Send Sequence
CS:
SC:
SC:
CS:
SC:
Send
AckStartSend
SendComplete
GetTpmStatus
TpmStatus
Properties we may want to verify
• It would be nice if we can verify properties about channel contracts
such as:
– After each SendComplete message is sent, eventually a Send or
GetTpmStatus message is sent
– The processes can reach the ReadyState with empty message
queues after the SendComplete and GetTpmStatus messages
are sent
Our Approach
• We know that verifying properties of asynchronously communicating
systems is difficult due to message queues
– Model checking such systems is undecidable even for finite state
process models if the message queues are unbounded
• We ask the following question:
– Can we identify asynchronously communicating systems where
asynchronous communication does not create new behaviors?
• We call such systems synchronizable
Verification via Synchronizability
• If a system is synchronizable, then
– behaviors of the system remain the same if we replace
asynchronous communication with synchronous communication
Synchronizable
asynchronous behaviors = synchronous behaviors
• If a system is synchronizable, then
– we can verify the synchronous version of the system
finite state processes + synchronous communication = finite state system
Synchronizable
verification results
for asynchronous
system
=
verification results
for synchronous
system
Equivalence of what type of behaviors?
Synchronizability in terms of
– Sequences of send actions
• Receive actions are considered local to the processes and their
ordering is not taken into account
– Reachability of states with no pending receives (we call such states
synchronized states)
• States with pending receives imply some process has not yet
reacted to messages sent to it, so the reachability of states
where the messages queues are not empty are not taken into
account
Three Examples, Example 1
!e
?a1
?e
?a2
!r1 !r2
requester
!a1
!a2
?r1 ?r2
server
• Sequences of send actions are identical for both asynchronous and
synchronous versions: (r1a1 | r2a2)* e
• During all executions the message queues use a fixed amount of
space
Example 2
!e
?a1
?e
?a2
!a1
!r1
!r2
requester
!a2
?r1 ?r2
server
• Sequences of send actions for the asynchronous version is not a
regular set and is not same as the synchronous version
• Queues can grow arbitrarily large
Example 3
!e !r
2
!r1
?a
!r
requester
?r1
!a
?e ?r
2
?r
server
• Sequences of send actions are identical for synchronous and
asynchronous versions: (r1 | r2 | ra)* e
• Queues can grow arbitrarily large
# of states in thousands
State Spaces of the Three Examples
1600
1400
1200
1000
800
Example 1
Example 2
600
Example 3
400
200
13
11
9
7
5
3
1
0
queue length
• Verification of Examples 2 and 3 are difficult even if we bound
the queue length
• Example 1 is synchronizable
• Example 2 is not synchronizable
• Example 3 is synchronizable, so it can be verified efficiently!
Contributions of this paper
Synchronizability definition in terms of
– Sequences of send actions
– Reachability of states with no pending receives, i.e., synchronized
states
• Necessary and sufficient condition for this definition of synchronizability
• Implementation and experiments on the Singularity channel contracts
Main Result
I0 : Synchronous System (0 size message queue)
Ik: Bounded Asynchronous System (k size message queue)
I : Asynchronous System (unbounded queue)
I0 equivalent to I1 iff Ik equivalent to I
Equivalence is defined as:
Identical set of send sequences and identical reachability of synchronized
states
Earlier Result
I0 equivalent to I1 iff Ik equivalent to I
When equivalence is defined as: Identical set of send sequences
Above condition was proved in an earlier paper:
“Choreography Conformance via Synchronizability”
[Basu and Bultan WWW’11]
In this paper we extend this earlier result by also considering reachability
of synchronized states
Proof Summary
• Assume I0 and I1 are equivalent
• Assume for some k: Ik has some synchronized trace absent in I1 or I0
• Show contradiction
Proof Summary
• Assume I0 and I1 are equivalent
• Assume for some k: Ik has some synchronized trace absent in I1 or I0
• Case 1: There exists a new reachable synchronized state that differs
from a prior one in exactly one local state
– Proof by contradiction leveraging the fact that I0 and I1 are
equivalent
Proof Summary
• Assume I0 and I1 are equivalent
• Assume for some k: Ik has some synchronized trace absent in I1 or I0
• Case 1: There exists a new reachable synchronized state that differs
from a prior one in exactly one local state
– Proof by contradiction leveraging the fact that I0 and I1 are
equivalent
• Case 2: There exists a new reachable synchronized state that differs
from a prior one in more that one local state
– Proof by contradiction leveraging Case 1
Implementation
• Implemented using CADP toolbox for checking synchronizability of
Singularity Channel Contracts
• We used the front end of an earlier tool called Tune for analyzing
Singularity channel contracts [Stengel, Bultan ISSTA 2009]
• We generate Lotos specifications for synchronized (I0) and 1-boundedasynchronous (I0) versions of the system
• Then we use the equivalence checking algorithms implemented in
CADP toolbox to check their equivalence
• Using Tune, we can also generate Promela specifications for
synchronized (I0) version which can then be used for model checking
behaviors of synchronizable channel contracts
Experimental Results
• Checked synchronizability of 86 Singularity Channel Contracts
– Synchronous Systems:
2 to 23 states; 1 to 60 transitions
– Asynchronous System with buffer size 1:
3 to 99 states; 2 to 136 transitions
• We first construct and reduce the synchronous and 1-bounded
asynchronous systems (takes about 10 secs on average) and then do
the equivalence checking (takes about 3 secs on average)
• 84 Contracts are synchronizable
• 2 contracts that are not synchronizable cause deadlocks!
– i.e., they are buggy!
Related Work
Synchronizability defined only in terms of equivalence of send action
sequences:
• [Fu et al. TSE’05]: Sufficient conditions for synchronizability to verify
asynchronously communicating Web services
– Similar sufficient conditions in [Honda et al. POPL’08] for session
types
• [Basu and Bultan WWW’11]: Necessary and sufficient condition for
synchronizability
Related Work
Restricted Asynchronous Communication:
• [Cece, Finkel Info. & Comp’05]: Reachability properties for half-duplex
systems
– At most one participating process has pending messages to be
consumed
• [Torre et al. TACAS’08]: Verification of asynchronous systems with
restricted communication topologies (e.g., tree)
Related Work
Slack elasticity [Manohar, Martin MPC 98]
• Presents conditions under which changing the size of communication
queues does not effect the behavior of the system
• Behavior definition also takes the decision points into account in
addition to message sequences
– does not consider the synchronized states
• It gives sufficient conditions for slack elasticity and discusses how to
construct systems to ensure slack elasticity
Related Work
• Singularity:
– [Hunt, Larus SIGOPS ‘07] Singularity: rethinking the software stack
– [Fähndrich, Aiken, Hawblitzel, et. al SIGOPS/Eurosys ‘07]
Language support for fast and reliable message-based
communication in singularity os.
– Influenced by work on Session Types
• [Honda, Vasconcelos, Kubo ESOP ’98] Language primitives
and type discipline for structured communication-based
programming
– Source code and RDK: http://codeplex.com/singularity
Related Work
• Synchronizability is also related to choreography realizability problem:
– [Fu, Bultan, Su TCS’04]
– [Kazhamiakin, Pistore FORTE’06]
– [Lohmann, Wolf ICSOC’11]
– [Basu, Bultan, Ouderni POPL’12]
Future Directions
• Beyond FIFO communication
– out-of-order consumption of messages
– unreliable messaging
• Beyond FSM for behavioral modeling
– Synchronizability of programs modeld as push-down systems
• Apply to different languages
THE END