Proving Dekker with SPIN and PROMELA

Joshua Wise

Greg Hartman

Show of hands

• Who...
• Had concurrency bugs during P2?
• Had concurrency bugs during P3?
• Had the same concurrency bugs during P2 and P3?
• Stayed up all weekend debugging the same concurrency bugs from P2 to P3?
• Really stayed up all weekend debugging the same concurrency bugs from P2 to P3, but won't admit it?

Concurrency bugs suck

• It's true.
• Race conditions make us sad.
• Wouldn't it be nice if we could prove that our code was free of race conditions?
• ...or that if it had race conditions, then at least they didn't produce undesirable behavior?
• ...in every possible case?

What's a race condition?

• Well, better, what's a program?
• A program can be represented by states and transitions.
• ...some are not so good.
• States tend to have just one transition.
• Sometimes, they have multiple; and if chosen nondeterministically, then we have a race condition.
• Interrupts, anyone?
• Not all races are bad.
• Program may well "converge" on correct state.

Multiple threads

• Threads change the game a bit
• Things are executed simultaneously, and always nondeterministically...
• ...which is one big race condition.
• So which races will make our program sad?

The saddest locks

• Let's take an example: the saddest mutexes
• mutex_lock is a no-op, and mutex_unlock is, too
• Some nameless TAs this semester unintentionally handed in a P3 that had these
• We'll have two threads, that each look like:

• {
    stuff
    mutex_lock();
    critical section
    mutex_unlock();
    end
  }

• Let's try to show that this won't work

The saddest state diagram

See?

• Obviously, that was no good.
• There were arrows leading into the state that we called "bad".
• Unfortunately, this doesn't scale.
• Try doing this on mutexes that do work!
• Many more states on just simple spinlocks
• Bakery/take-a-number: oh no!
• Key thing: after every instruction, an interrupt could occur.

Introducing SPIN

• Luckily, there's a program that will do this for us
• SPIN compiles programs into states
• ... and exhaustively searches statespace
• Some questions raised, such as "what is bad?"
• Programs specified in a C-ish language called PROMELA
• "PROcess MEta LAnguage"
• This will be on the final
• (not really)
• Better suited for verifying hardware
• We'll convince it to verify some locking algorithms for us today

The saddest locks, revisited

• Let's do that again, but with more PROMELA this time.

• byte t0_incrit = 0; byte t1_incrit = 0; inline mutex_lock() { skip; } inline mutex_unlock() { skip; } proctype A() { t0_incrit = 0; /* Some stuff */ mutex_lock(); t0_incrit = 1; /* Hi! */ t0_incrit = 0; /* Ok, done */ mutex_unlock(); }

  proctype B() { t1_incrit = 0; /* Some stuff */ mutex_lock(); t1_incrit = 1; /* Hi! */ t1_incrit = 0; /* Ok, done */ mutex_unlock(); } init { run A(); run B(); }

What about the actual checking?

• Let's run it:

• $ spin -a saddest.promela
  $ gcc -o pan pan.c
  $ ./pan
  (Spin Version 4.3.0 -- 22 June 2007)
          + Partial Order Reduction
  [...]
  $

• Nothing happened?
• Not quite
• SPIN checked all states, but not for anything useful

Verifying mutual exclusion

• Some changes:

• proctype monitor()
  {
          assert(!(t0_incrit && t1_incrit));
  }
  
  init {
          run A();
          run B();
          run monitor();
  }
  

Run it again

• Another build cycle:

• $ spin -a saddest.promela
  $ gcc -o pan pan.c
  $ ./pan
  pan: assertion violated  !((t0_incrit&&t1_incrit)) (at depth 9)
  pan: wrote saddest.promela.trail
  [...]
  

• Aha!
• The assertion was violated, and it wrote out a trail telling us where.

What went wrong?

• XSPIN can tell us, or pan can tell us
• pan -C: read in the trail, and give annotation

• $ ./pan -C
  1: :init:(0):[(run A())]
  2: :init:(0):[(run B())]
  3: :init:(0):[(run monitor())]
  4:                              B(2):[t1_incrit = 0]
  5:                              B(2):[(1)]
  6:                              B(2):[t1_incrit = 1]
  7:              A(1):[t0_incrit = 0]
  8:              A(1):[(1)]
  9:              A(1):[t0_incrit = 1]
  pan: assertion violated  !((t0_incrit&&t1_incrit)) (at depth 10)
  spin: trail ends after 10 steps

• Concrete path: what went wrong

Slightly happier mutexes

• One more example
• Spinlocks: this time, with more mutual exclusion!
• mutex_lock will spin-wait on a single 'locked' variable.
• For the example we gave, guaranteed to terminate -- why?

New PROMELA code

byte locked = 0;

inline mutex_lock()
{
        do
        :: 1 ->
             atomic {
               if
               :: locked == 0 -> locked = 1; break;
               :: else -> skip;
               fi
             }
        od
}

New PROMELA code 2

inline mutex_unlock()
{
        assert (locked == 1);
        locked = 0;
}

Any better?

• Well, let's find out:

• $ spin -a happier.promela
  $ gcc -o pan pan.c
  $ ./pan
  [...]
  State-vector 28 byte, depth reached 27, errors: 0
  [...]

• Sweet.
• But what about other properties of mutexes?
• Progress
• Bounded waiting

Unbounded waiting

• Only showing bounded waiting for time
• PROMELA feature: "progress cycles"
• Don't get hosed!
• In an infinite cycle, a progress cycle must be hit infinitely often
• Who can tell me an execution path that makes spinlocks sad?
• Let's see if we can get SPIN to produce this for us
• Game plan: insert 'progress' cycle in a loop after both people get to run

New monitor process

proctype fairness() {
        do
        :: 1 ->
                t0_incrit -> skip;
                t1_incrit -> skip;
progress:       skip
        od
}

[...]
        run fairness();
[...]

Is it fair?

$ spin -a happier-progress.promela
$ gcc -o pan pan.c -DNP
$ ./pan -l
pan: non-progress cycle (at depth 20)
pan: wrote happier-progress.promela.trail
[...]
State-vector 36 byte, depth reached 35, errors: 1
[...]

• As we guessed, something went wrong
• SPIN made a state tree for us
• ...and found a series of transitions that break bounded waiting!

What went wrong? 2

$ ./pan -l -C
[...]
<<<<<START OF CYCLE>>>>>
22:                               B(3):[((locked==0))]
24:                               B(3):[break]
26:                               B(3):[t1_incrit = 1]
28:                               B(3):[t1_incrit = 0]
30:                               B(3):[assert((locked==1))]
32:                               B(3):[locked = 0]
34:                               B(3):[(1)]
36:                               B(3):[(1)]

On to Dekker

• Dekker's Algorithm
• T. J. Dekker, 1964
• 2 threads only
• Guarantees the Big Three
• Let's try to prove it
• Mutual exclusion
• Bounded waiting
• SPIN style warning!
• Namely, mine is bad.

Mutual Exclusion

• Let's write some PROMELA!

proctype A()
{
  f0 = 1;
  do
  :: f1 ->
    if
    :: turn != 0 ->
      f0 = 0;
      turn == 0 -> skip;
      f0 = 1;
    :: else -> skip;
    fi
  :: else -> break;
  od;

  t0_incrit = 1;
  t0_incrit = 0;

  turn = 1;
  f0 = 0;
}

proctype B()
{
  f1 = 1;
  do
  :: f0 ->
    if
    :: turn != 1 ->
      f1 = 0;
      turn == 1 -> skip;
      f1 = 1;
    :: else -> skip;
    fi
  :: else -> break;
  od;

  t1_incrit = 1;
  t1_incrit = 0;

  turn = 0;
  f1 = 0;
}

And, as we expect...

$ spin -a dekker.promela
$ gcc -o pan pan.c
$ ./pan
[...]
State-vector 32 byte, depth reached 29, errors: 0
[...]

• So the two threads will never fail for one iteration.
• Can we show that they'll always have bounded waiting?

Bounded waiting

• Let's try a different tactic
• "Every time you are waiting for the lock, you eventually get the lock"

• proctype fairness0() {
          f0 -> t0_incrit;
  }
  
  proctype fairness1() {
          f1 -> t1_incrit;
  }

• And, we'll also put the procedures in loops like we did before.
• This is a slightly weaker form of bounded waiting
• ...which is not quite ACTUAL bounded waiting.

As we expect 2

$ spin -a dekker-waiting.promela
$ gcc -o pan pan.c
$ ./pan
[...]
State-vector 40 byte, depth reached 106, errors: 0
[...]

• Yes!
• Everything reached a valid end state, so there are no errors
• Always!
• Dekker's algorithm provides bounded waiting

Limitations

• State explosion problems
• Machines are better than people...
• ...but only by six or seven orders of magnitude.
• Running RCU verification on Linux
• 1 updater, 1 reader: 2.6mbyte
• 1u, 2r: 2.9mbyte
• 2u, 2r: 75.4mbyte
• 2u, 3r: 2,715.2mbyte...
• 3u, 2r: 14,979.9 mbyte!
• Small world theory
• Extending proof to more
• Non-trivial? Trivial?

Summary

• Race conditions suck
• It is possible to think of programs in a more deterministic fashion
• Programs exist to prove other programs
• ...but those programs are mostly science fair toys
• Questions?
• PROMELA files available to play with tonight, look for an e-mail