Zing Concurrent Software MC

Document Sample
Zing Concurrent Software MC Powered By Docstoc
					          ZING
 Systematic State Space
Exploration of Concurrent
        Software
             Jakob Rehof
          Microsoft Research
http://research.microsoft.com/~rehof
 http://research.microsoft.com/zing

              Joint work with
            Tony Andrews (MS)
            Shaz Qadeer (MSR)
        Sriram K. Rajamani (MSR)
         Lecture II: Outline
• ZING language
• Demos
  – LTM analysis
  – X86 -> ZING
• Procedure Summaries
• Conformance Theory (I)
           Zing Language
• Zing = C# - some types – inheritance +
  concurrency + modeling features

• Concurrency = shared memory +
  message-passing

• Modeling features = nondeterminism +
  sets + symbolic execution
                Concurrency

static activate void foo()
{
  …
}


async-call-statement
   async invocation-expression
                     Modeling
choose-expression
   choose( type )
   choose( primary-expression )

event-statement
   event(integer-expression,
          integer-expression,
          boolean-expression)


set-declaration
    set identifier type
                  Channels


channel-declaration:
   chan identifier type



send-statement
   send(expression, expression);
               Synchronization

select-statement
   select [select-qualifiers] { join-statements }

select-qualifier
    end first visible

join-statement
    join-list -> embedded-statement
    timeout -> embedded-statement
              Synchronization

join-list
    join-pattern
    join-list && join-pattern

join-pattern
    wait(boolean-expression)
    receive(expression, expression)
    event(integer-expression,
           integer-expression,
           boolean-expression)
         Lecture II: Outline
• ZING language
• Demos
  – LTM analysis
  – X86 -> ZING
• Procedure Summaries
• Conformance Theory (I)
                 Indigo Transaction Manager
                     Abstracting the LTM
                            LTM

                   DTM
   Client        (20K LOC)                    Volatile RM
   (main)                                      interface

                                               Prepare
                                               Rollback      VRM
   CreateTx                                     Commit      (cache)
    CloneTx                  Prepared
DurableEnlist       LTM
                             ForceRollback
VolatileEnlist   (10K LOC)
                             EnlistmentDone
     Commit
                                                Prepare
        Abort                                                DRM
                                                Rollback
                              LTM interface                 (dbase)
LTM interface                                    Commit
                                to RMs
  to Client
                                              Durable RM
                                               interface
                   Overview of the bug

                         • Transactions tx1 and tx2 must be
                           inserted in the same bucket of the hash
                           table.
      …                  • Transaction tx2 is a bystander that
                           ensures that tx1.next is non-null (a
256          tx1   tx2
                           necessary precondition).
      …
                         • Transaction tx1 is committed. The
                           commit thread and the timer thread
                           interleave (4 context switches at specific
hash table                 locations) such that tx1.next is set to
                           null by the timer thread and subsequently
                           dereferenced by the commit thread.
         Lecture II: Outline
• ZING language
• Demos
  – LTM analysis
  – X86 -> ZING
• Procedure Summaries
• Conformance Theory (I)
         Lecture II: Outline
• ZING language
• Demos
  – LTM analysis
  – X86 -> ZING
• Procedure Summaries
• Conformance Theory (I)
      Procedure Summaries for
        Concurrent Programs
• Generalized CFL-Reachability Algorithm
  – Qadeer, Rajamani, Rehof:
    Summarizing Procedures in Concurrent Programs.
   [POPL 2004]
• Implemented in ZING
  – Approx. one year sustained effort
    Summarization for sequential
            programs
• Procedure summarization (Sharir-Pnueli
  81, Reps-Horwitz-Sagiv 95) is the key to
  efficiency
    int x;               void main() {
                           …
    void incr_by_2() {     x = 0;
       x++;                incr_by_2();
       x++;                …
    }                      x = 0;
                           incr_by_2();
                           …
                         }

• Bebop, ESP, Moped, MC, Prefix, …
 What is a summary in sequential
            programs?
• Summary of a procedure P = Set of all
  (pre-state  post-state) pairs obtained by
  invocations of P
     int x;               void main() {    x      x’
                            …
     void incr_by_2() {     x = 0;         0      2
        x++;                incr_by_2();   1      3
        x++;                …
     }                      x = 0;
                            incr_by_2();
                            …
                            x = 1;
                            incr_by_2();
                            …
                          }
        Assertion checking for
         sequential programs
• Boolean program with:
  – g = number of global vars
  – m = max. number of local vars in any scope
  – k = size of the CFG of the program
                           O(g+m)
• Complexity is O( k  2     ), linear in
  the size of CFG
• Summarization enables termination in the
  presence of recursion
       Assertion checking for
       concurrent programs

Ramalingam 00:
There is no algorithm for assertion checking
of concurrent boolean programs, even with
only two threads.
           Our contribution
• Precise semi-algorithm for verifying
  properties of concurrent programs
  – based on model checking
  – procedure summarization for efficiency
• Termination for a large class of concurrent
  programs with recursion and shared
  variables
• Generalization of precise interprocedural
  dataflow analysis for sequential programs
 What is a summary in concurrent
            programs?
• Unarticulated so far
• Naïve extension of summaries for
  sequential programs do not work


           Call P        Return P
                  Attempt 1
           s
                Advantage: summary computable as in a sequential
  Call P        program

                Disadvantage: summary not usable for executions with
                interference from other threads




Return P
           s’
                   Attempt 2
           s
  Call P        Advantage: Captures all executions



                Disadvantage: s and s’ must comprise full program state
                • summaries are complicated
                • do not offer much reuse




Return P
           s’
  The theory of movers (Lipton 75)
                                         r=foo
                                           acq         y
                                                       x
•R: right movers                   S20
                                   S             S3
                                                 S1           S42
                                                              S
  – lock acquire
 L: left movers                           x
                                           y          acq
                                                      r=foo
                                   S
                                   S20           T3
                                                  1           S
                                                              S42
  – lock release
                                           zx     rel
                                                    r=foo
 B: both right + left movers      S2
                                    5            S3
                                                  6           S4
                                                               7
  – variable access holding lock
 N: non-movers                           rel
                                         r=foo          z
                                                        x
                                S5
                                S2               T6
                                                 T3           S7
                                                              S4
  – access unprotected variable
                     Transaction
Lipton: any sequence (R+B)*; (N+) ; (L+B)* is a transaction


       S0
            R*
                 .   x
                          .   N
                                  .   Y
                                           .   L*
                                                    S5

       S0
            x
                 .   R*
                          .   N
                                  .   L*
                                           .   Y
                                                    S5

   Other threads need not be scheduled in the middle
   of a transaction
      Transactions may be summarized
If a procedure body is a single transaction,
summarize as in a sequential program
bool available[N];
mutex m;
                                   Choose N = 2
int getResource() {
     int i = 0;
L0: acquire(m);                   Summaries:
L1: while (i < N) {                m, (a[0],a[1])      i’, m’, (a[0]’,a[1]’) 
L2: if (available[i]) {
L3:       available[i] = false;
L4:       release(m);              0, (0, 0)          2, 0, (0,0) 
L5:       return i;                0, (0, 1)          1, 0, (0,0) 
        }                          0, (1, 0)          0, 0, (0,0) 
L6: i++;                           0, (1, 1)          0, 0, (0,1) 
      }
L7: release(m);
L8: return i;
}
    Transactional procedures
• In the Atomizer benchmarks (Flanagan-
  Freund 04), a majority of procedures are
  transactional
   What if a procedure body comprises multiple
   transactions?
bool available[N];
                                  Choose N = 2
mutex m[N];
                                  Summaries:
int getResource() {                pc,i,(m[0],m[1]),(a[0],a[1])      pc’,i’,(m[0]’,m[1]’),(a[0]’,a[1]’) 
     int i = 0;
L0: while (i < N) {
L1: acquire(m[i]);                 L0, 0, (0,*), (0,*)    L1, 1, (0,*), (0,*) 
L2: if (available[i]) {            L0, 0, (0,*), (1,*)    L5, 0, (0,*), (0,*) 
L3:       available[i] = false;
L4:       release(m[i]);
L5:       return i;                L1, 1, (*,0), (*,0)    L8, 2, (*,0), (*,0) 
       } else {                    L1, 1, (*,0), (*,1)    L5, 1, (*,0), (*,0) 
L6:       release(m[i]);
       }
L7: i++;
     }
L8: return i;
}
What if a transaction
1. starts in caller and ends in callee?
2. starts in callee and ends in caller?
                      int x;
                      mutex m;
    void foo() {                 void bar() {
      acquire(m);
      x++;               1
                                     release(m);
        bar();
                         2           acquire(m);
        x--;
        release(m);              }
    }
What if a transaction
1. starts in caller and ends in callee?
2. starts in callee and ends in caller?
                      int x;
                      mutex m;
    void foo() {                 void bar() {
      acquire(m);
      x++;               1
                                     release(m);
        bar();
                         2           acquire(m);
        x--;
        release(m);              }
    }

Solution:
1. Split the summary into pieces
2. Annotate each piece to indicate whether
   transaction continues past it
    Two-level model checking
• Top level performs state exploration
• Bottom level performs summarization
• Top level uses summaries to explore
  reduced set of interleavings
  – Maintains a stack for each thread
  – Pushes a stack frame if annotated summary
    edge ends in a call
  – Pops a stack frame if annotated summary
    edge ends in a return
                Termination
• Theorem:
  – If all recursive functions are transactional,
    then our algorithm terminates.
  – The algorithm reports an error iff there is an
    error in the program.
          Concurrency + recursion
        int g = 0;
        mutex m;
                                             Summaries for foo:
void foo(int r) {      void main() {
                                              pc,r,m,g    pc’,r’,m’,g’ 
L0: if (r == 0) {          int q =
L1:     foo(r);            choose({0,1});
                                              L0,1,0,0    L5,1,0,1 
    } else {           M0: foo(q);
L2:     acquire(m);                           L0,1,0,1    L5,1,0,2 
                       M1: acquire(m)
L3:     g++;           M2: assert(g >= 1);
L4:     release(m);    M3: release(m);
    }                  M4: return;
L5: return;            }
}


         Prog = main() || main()
               Summary (!)
• Transactions enable summarization
• Identify transactions using the theory of
  movers
• Transaction boundaries may not coincide
  with procedure boundaries
  – Two level model checking algorithm
  – Top level maintains a stacks for each thread
  – Bottom level maintains summaries
        Sequential programs
• For a sequential program, the whole
  execution is a transaction
• Algorithm behaves exactly like classic
  interprocedural dataflow analysis

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:3
posted:5/18/2012
language:English
pages:34
fanzhongqing fanzhongqing http://
About