SPIN: Some examples - PowerPoint PPT Presentation

1 / 22
About This Presentation
Title:

SPIN: Some examples

Description:

http://spinroot.com/spin/Man/Exercises.html. e.g. Go-Back-N Sliding Window Protocol ... Nasty fault, after two consecutive 'errors' 13. 1. 3. 2. 4 !1,data ... – PowerPoint PPT presentation

Number of Views:66
Avg rating:3.0/5.0
Slides: 23
Provided by: wis66
Category:
Tags: spin | com | examples

less

Transcript and Presenter's Notes

Title: SPIN: Some examples


1
SPIN Some examples
2
Alternating bit protocol
s2r
sender
receiver
r2s
  • connections in both directions imperfect, but
    corrupted data can be detected (e.g. with
    checksum etc).
  • Basic idea
  • send data, wait for a positive acknowledgement
    before sending the next one (so, no buffered
    send).
  • well just use a single bit to implement
    acknowledgement mechanism.

3
You can think of several ways to do it ...
  • A note on reliable full-duplex transmission over
    half-duplex links, K. A. Bartlett, R. A.
    Scantlebury, P. T. Wilkinson, Communications of
    the ACM, Vol 12, 1969.
  • NPL Protocol
  • Mlt2 Protocol (well discuss this one)
  • For more, check out http//spinroot.com/spin/Ma
    n/Exercises.htmle.g. Go-Back-N Sliding Window
    Protocol

4
Mlt2 Protocol, Sender part
Fetch a new data.
1
!1,data
?1
!0,data // Sender wants to resend
2
4
error
?0 // Receiver wants Sender to resend
!1,data
3
State 1 is the starting state, and its accepting
state in the sense when the sender is in this
state, it assumes the last data package it sent
has been successfully received by the receiver,
and so it fetches a new data package to send.
5
Mlt2 Protocol, Receiver part
1
!0 // request Sender to resend
error
!1
2
4
?0,rd // Sender wants Receiver to resend
?1,rd
!1
3
6
Side by side
Fetch a new data.
1
1
!1,data
!0 // request Sender to resend
?1
error
!0,data // Sender wants to resend
!1
2
4
2
4
error
?0,rd // Sender wants R to resend
?0 // Receiver wants S to resend
!1,data
?1,rd
!1
3
3
Though each automaton is simple, the combined
(and concrete) behavior is quite complex ? 100
states in my (abstract) SPIN model (there are
more explicit states, if we take the data into
account).
7
Ideal scenario
Fetch a new data.
1
1
!1,data
!0 // request Sender to resend
?1
error
!0,data // Sender wants to resend
!1
2
4
2
4
error
?0,rd // Sender wants R to resend
?0 // Receiver wants S to resend
!1,data
?1,rd
!1
3
3
8
Two sucessive errors scenario
Fetch a new data.
1
1
!1,data
!0 // request Sender to resend
?1
error
!0,data // Sender wants to resend
!1
2
4
2
4
error
?0,rd // Sender wants R to resend
?0 // Receiver wants S to resend
!1,data
?1,rd
!1
3
3
9
Modelling in SPIN
proctype Receiver(chan in, out) show byte rd
/ received data / show bit cbit
/ control bit / do in?cbit,rd
progress if (cbit 1) -gt out!1
(cbit 0) -gt out!1
printf("MSC ERROR1\n") out!0 fi od
chan S2R BufSize of bit, byte chan R2S
BufSize of bit
init atomic run Sender(R2S,
S2R) run Receiver(S2R, R2S)
So, how much is BufSize? Well try 1, and use
the verifier to check that the model wont
deadlock ? using progress label is not
sufficient check ltgt Receiver_at_progress.
10
Perhaps a more 1-1 model with goto ?
proctype Sender(chan in, out) show byte data
/ message data / show bit cbit /
received control bit / S1 data (data1)
MAX out!1,data S2 in ? cbit
if (cbit 1) -gt goto S1
(cbit 0) / goto S3 /
printf("MSC AERROR1\n") -gt goto S4 fi
S3 out!1,data goto S2 S4
out!0,data goto S2
11
Specification
Each data package, if accepted by the receiver,
will be accepted exactly once!
  • express this with LTL?
  • We can also express it with assertion
  • exploit that sender generates new data by data1
  • introduce last ? previous accepted data
  • Impose this on the acceptance state (of
    R) current data received last 1

12
Incorporating the spec
proctype Receiver(chan in, out) show byte rd
/ received data / show bit cbit
/ control bit / do in?cbit,rd
progress if (cbit 1) -gt out!1
(cbit 0) -gt out!1
printf("MSC ERROR1\n") out!0 fi od
show byte last
assert (rd last1 MAX) last rd
This is the Receivers accepting state S3
13
Nasty fault, after two consecutive errors
Fetch a new data.
1
1
!1,data
!0 // request Sender to resend
?1
error
!0,data // Sender wants to resend
!1
2
4
2
4
error
?0,rd // Sender wants R to resend
?0 // Receiver wants S to resend
!1,data
?1,rd
!1
3
3
14
Example distributed sorting
1 31
  • Idea
  • Spec

0 193
Network
Let P(i) swap values with P(i1).
2 333
3 31
Eventually the values will be sorted.
15
SPIN model
init byte i do iltN -gt if
aione aitwo
... fi i else -gt
break od i0 do ilt N - 1 -gt run
P(i) i else -gt run detect()
break od
define N 5 mtype one, two, three, four
mtype aN proctype P(byte i) byte tmp
do d_step aigtai1 -gt
tmpai aiai1
ai1tmp tmp0 od
Swap values, set tmp back to 0 to save state.
16
Expressing the spec
Eventually the values will be sorted.
ltgt (?i 0?iltN-1 ai?ai1)
With LTL
But SPIN does not support quantification in its
Expr. You will have to write your own
never-claim, and self-implement the
quantification.
never init if (! p)
-gt goto accept goto init
fi accept goto init
Insert a code here to check the above
quantification.
goto and break are 0-time steps in SPIN,
except when nothing preceed it, then it is a
single step.
17
Neverclaim
  • From SPIN perspective, a neverclaim is just
    another process, but it is executed in lock-step
  • it is always executed first
  • After each step of the system, we execute a step
    from the neverclaim.
  • Is used to express properties
  • We can just use plain assertions (inside
    neverclaim) to express this
  • Or use acceptance states

18
Neverclaim
never do assert (b) assert (!b)
od
Expressing the value of b should be alternating.
never init if (!p)
-gt goto accept goto init
fi accept goto init
Error when there is a lock -step executions that
cycles in an accepting state.
19
Spec of dsort, with neverclaim
never init if
(! ok) -gt goto accept goto init
fi accept goto init
put this in an atomic block.
ok true j0 do jltN-1 -gt if
ajaj1 -gt okfalse break
else -gt j fi else -gt break od j0
put this in an atomic block. Better yet, a
d_step block.
20
Another way...
Eventually the values will be sorted.
proctype detect() byte i timeout -gt
do iltN-1 -gt assert (ailtai1)
else -gt break od
exploit timeout to detect stable state.
21
Detecting termination
New spec we want each P(i) to know that the
goal (to sort values) has been acomplished.
proctype detect() byte i timeout -gt
do iltN-1 -gt assert (ailtai1)
else -gt break od
done true
Extend P(i), such that when it sees done is
true, it will terminate.
Unfortunately, not good enough. The above
solution uses timeout which here serves as a
mechanism to detect termination in the actual
system we now assume not to have this mechanism
in the first place, and hence have to implement
it ourselves.
22
Detecting termination
Idea let detect keep scanning the array to
check if it is sorted.
Unfortunately, this doesnt work perfectly.
Consider this sequence of steps 4, 5, 1
detect 0,1 ? ok swap 1,2
4, 1, 5 detect 1,2 ? ok now
detect concludes termination! Can you find a
solution for this??
proctype detect() byte i i0 do
iltN-1 -gt if aigtai1 -gt
break else -gt i
fi else -gt donetrue break od
Write a Comment
User Comments (0)
About PowerShow.com