Synchronizability for verification of asynchronously communicating systems
Download
1 / 33

Synchronizability for Verification of Asynchronously Communicating Systems - PowerPoint PPT Presentation


  • 89 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Synchronizability for Verification of Asynchronously Communicating Systems' - merv


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Synchronizability for verification of asynchronously communicating systems

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
Asynchronously Communicating Systems 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
Asynchronous Messaging Communicating Systems

  • 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
Objective & Challenge Communicating Systems

  • 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
Motivation: Singularity OS Communicating Systems

  • 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
Singularity Channels Communicating Systems

  • 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
Channel Contracts Communicating Systems

  • Written in Sing #

  • Contracts specify two things:

    • 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)

    • The set of allowed message sequences

      • out message marked with !

      • in messages marked with ?

publiccontract KeyboardDeviceContract {

outmessage AckKey( uint key );

outmessage NakKey();

outmessage Success();

inmessage GetKey();

inmessage PollKey();

state Start {

Success! -> Ready;

}

state Ready {

GetKey? -> Waiting;

PollKey? -> (AckKey! or NakKey!)

-> Ready;

}

state Waiting {

AckKey! -> Ready;

NakKey! -> Ready;

}

}


Channel contracts1
Channel Contracts Communicating Systems

  • A contract specifies a finite state machine

  • Each message causes a transition from one state to another state

    KeyboardDeviceContract

publiccontract KeyboardDeviceContract {

outmessage AckKey( uint key );

outmessage NakKey();

outmessage Success();

inmessage GetKey();

inmessage PollKey();

state Start {

Success! -> Ready;

}

state Ready {

GetKey? -> Waiting;

PollKey? -> (AckKey! or NakKey!)

-> Ready;

}

state Waiting {

AckKey! -> Ready;

NakKey! -> Ready;

}

}

Start

SC:AckKey

SC:AckKey

SC:Success

Implicit State

CS:PollKey

CS:GetKey

Waiting

Ready

Ready$0

SC:AckKey

SC:NakKey


Singularity channel contract verification
Singularity Channel Contract Verification Communicating Systems

  • 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
Bad Things Can Happen Communicating Systems:The TpmContract

Server

ReadyState$0

Send Sequence

Server

Receive Queue

Send?

AckStartSend!

CS: Send

SC: AckStartSend

SC: SendComplete

CS: GetTpmStatus

SC: TpmStatus

SendComplete!

GetTpmStatus

Send

ReadyState

IO_RUNNING

TpmStatus!

TpmStatus!

GetTpmStatus?

GetTpmStatus?

ReadyState$1

IO_RUNNING$0

Stuck!

Client

ReadyState$0

Client

Receive Queue

Send!

AckStartSend?

SendComplete?

SendComplete

AckStartSend

ReadyState

IO_RUNNING

TpmStatus

TpmStatus?

TpmStatus?

GetTpmStatus!

GetTpmStatus!

ReadyState$1

IO_RUNNING$0


Properties we may want to verify
Properties we may want to verify Communicating Systems

  • 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
Our Approach Communicating Systems

  • 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
Verification via Synchronizability Communicating Systems

  • 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

verification results

for synchronous

system

verification results

for asynchronous

system

=

Synchronizable


Equivalence of what type of behaviors
Equivalence of what type of behaviors? Communicating Systems

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
Three Examples, Example 1 Communicating Systems

  • 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

!e

?e

?a1

!a1

?a2

!a2

!r1

!r2

?r1

?r2

requester

server


Example 2
Example 2 Communicating Systems

  • 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

!e

?e

?a1

?a2

!a1

!a2

!r1

!r2

?r1

?r2

requester

server


Example 3
Example 3 Communicating Systems

?e

!e

?r1

!r1

?r2

!r2

!a

?r

?a

!r

requester

server

  • Sequences of send actions are identical for synchronous and asynchronous versions: (r1 | r2 | ra)* e

  • Queues can grow arbitrarily large


State spaces of the three examples
State Spaces of the Three Examples Communicating Systems

# of states in thousands

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
Contributions of this paper Communicating Systems

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
    Main Result Communicating Systems

    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
    Earlier Result Communicating Systems

    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
    Proof Summary Communicating Systems

    • Assume I0 and I1 are equivalent

    • Assume for some k: Ik has some synchronized trace absent in I1 or I0

    • Show contradiction


    Proof summary1
    Proof Summary Communicating Systems

    • 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 summary2
    Proof Summary Communicating Systems

    • 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
    Implementation Communicating Systems

    • 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-bounded-asynchronous (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
    Experimental Results Communicating Systems

    • 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
    Related Work Communicating Systems

    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 work1
    Related Work Communicating Systems

    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 work2
    Related Work Communicating Systems

    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 work3
    Related Work Communicating Systems

    • 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 work4
    Related Work Communicating Systems

    • 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
    Future Directions Communicating Systems

    • 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
    THE END Communicating Systems


    ad