View
234
Download
6
Embed Size (px)
Citation preview
1
מפרטים פורמאליים10תירגול מספר
Lamport
Based on the paper:“specifying concurrent program modules” by Leslie Lamport(ACM Transaction on programming languages and systems Vol. 5 April 1983,
pages 190-222)
שחר דגמפרטים פורמאליים - תירגול
queue
2
הגדרה מקוצרת
שחר דגמפרטים פורמאליים - תירגול
שיטה להגדרת תוכניות מקביליות / מבוזרות
מודול הוא אוסף של סברוטינות
במקום להגדיר את הקשר בין קלט לפלט, אנו מדברים על סדרות חישוב ומגדירים אילו שינויים )מעברים( ניתן לבצע ואילו לא
בצורה זו ניתן להגדיר את ההתנהגות של כל סברוטינה:ההתנהגות המותרת של הסברוטינה•דברים כמו המתנה של הסברוטינה לאירועים חיצוניים )דבר שלא ניתן •
להגדיר במפרט ק/פ(ההתנהגות המותרת של הסביבה )למשל מה לא ניתן לשנות בזמן •
שהסברוטינה רצה(
3
המודל החישובי
שחר דגמפרטים פורמאליים - תירגול
ביצוע של תוכנית מקבילית מיוצג על ידי סידרת מעברים s ,הוא המצב ההתחלתיs’הוא המצב הסופי s היא הפעולה שמעבירה את המערכת ממצב αו
.’sלמצב מקביליות מיוצגת ע"י ערבוב של פעולות אטומיות
( של המערכת בנקודת זמן כלשהי. הוא יכיל את snapshotמצב מהווה הקפאה )ערכי המשתנים, מצב המחסנית, מצב האוגרים ואת כל שאר משתני המערכת.
)הצעד הבא מוכתב רק ע"י המצב הנוכחי ולא ע"פ המסלול בו הגענו אליו(
'ss
כל החישובים הם אין סופיים. חישוב סופי מומר לחישוב אין סופי ע"י הוספת מעבר ריק מהמצב הסופי לעצמו.
stateלא נתייחס למצב המערכת באופן ישיר אלא באמצעות פונקציות מצב )function.)
נשתמש בפונקציות כדי לברר את ערכי המשתנים וכדי לברר היכן בתוכנית אנו הוא מקום בתוכנית(π כאשר )π(atנמצאים )
4
)הערות(המודל החישובי
שחר דגמפרטים פורמאליים - תירגול
אנו לא מכירים את הפעולות האטומיות של המערכת.אנו רק יודעים מה השינויים המותרים בפונקצית המצב האבסטרקטית.
אנו לא מתייחסים לפעולות שלא משנות את פונקצית המצב
פעולות שמשנות את פונקצית המצב, עושות זאת רק בהתאם לתנאים בחלק של “allow changes” ולכן אנו מדברים על תכונות safety
5
המפרט
שחר דגמפרטים פורמאליים - תירגול
מפרט של תוכנית מתואר על ידי:
State function: f1:R1, … , fn:Rn
Initial condition: I1, … , Im
Properties: P1, … , Pq
THERE EXIST state functions f1, … , fn SUCH THAT:The range of fi is Ri, for each i, ANDIF the initial state satisfies I1, … Im
THEN properties P1, … , Pq are satisfied throughout the execution.
ומשמעותו:
המפרט חייב להישמר בכל חישוב אפשרי )ביצוע( של התוכנית
מה התחום של ? הפונקציות
כל המצבים של התוכנית
6
safety properties
שחר דגמפרטים פורמאליים - תירגול
מגדיר מה תמיד חייב להיות נכון.ניתן להגדיר תכונות בטיחות באחת משלוש צורות:
1. A predicate that must be true in every state of the program )invariant(
2. Asserting when a state function cannot change:a leaves unchanged f when Q
A – a set of actionsf – a state functionQ – predicate
if state s satisfies Q, and a is in the set A and a changes the state of the system from s to s’, then f)s( = f)s’(
.(f)לא ניתן להבדיל בין המצב שלפני למצב שאחרי ע"י פונקצית המצב
'ss a
אם נכון aניתן להשמיט את •לכל פעולה אפשרית
whenניתן להשמיט את "•Q אם רוצים שיהיה תקף "
תמיד
7
safety properties )cont.(
שחר דגמפרטים פורמאליים - תירגול
3. Describing when a state function can change:
allowed changes to f1 when Q1, … , fi when Qi
a1: R1 → S1
.
.
.
aj: Rj→ Sj
fi – state function
Qi – predicate
aj – set of actions
Rj – predicate
Sj – boolean function expressed with state functions
For every transition
In the execution, if Qi is true for
state s and fi)s( ≠ fi)s’( then there
is some j that:
1. α is in aj
2. Rj is true for state s
3. Rj is false for state s’
4. Sj is true for the pair )s, s’(
'ss
If Sj doesn’t include a primed version of
fi, we assume it preserves it’s value
8
liveness properties
שחר דגמפרטים פורמאליים - תירגול
מגדיר מה חייב לקרות )בסופו של דבר(.liveness לשם הגדרת Linear Temporal Logicנשתמש ב
בהינתן סידרת החישוב הבאה:
...... 1210121
ii sssss ii
(: si )כאשר התוכנית נמצאת במצב iנגדיר כי בזמן
P: true at time i, if and only if it is true on state si⃞P: true at time i, if and only if P is true at all time j ≥ i⃟P: true at time i, if and only if P is true at some time j ≥ i⃞⃟P: true at time i, if and only if P is true at infinitely many times j ≥ i
: p ⇝ q:ולהזכירכם את הקיצור )p → q( ⃞⃞ ⃞⃟
10
דוגמא
שחר דגמפרטים פורמאליים - תירגול
אנו רוצים לממש העברת הודעות בערוץ לא אמין )דהינו חלק מההודעות הולכות לאיבוד(. אנו רוצים להבטיח כי אם הודעה מסוימת תשלח מספיק פעמים וכי אם
מספיק פעמים ינסו לקרוא אותה, אזי בסופו של דבר ההודעה תעבור.
ראשית נשנה את התור כך שירשה לאבד הודעות.דרושים לנו שני שינויים:
כך שתרשה איבוד הודעות.3שינוי תכונה 1.
תנאי ה"חיות" המקורי לא מספיק מכיוון שהתור יכול לאבד הודעות בדיוק 2. להחזיר תשובה רק RCV, לכן שינינו אותו כך שידרוש מ GETכשאנחנו נכנסים ל
אחרי "הרבה ניסיונות"
11שחר דגמפרטים פורמאליים - תירגול
התור שמאבד הודעות
TMT replaces PUTRCV replaces GET
In 3)c(, ≺ denotes the relation “is a proper sub-sequence of”
In 5, if in)RCV( and infinitely often the queue is not empty, then eventually we will exit RCV
)reminder: p ⇝ q : )p → q(( ⃞⃞ ⃞⃟new
changed
12
)המשך(התור שמאבד הודעות
שחר דגמפרטים פורמאליים - תירגול
אנו רואים שכל הודעה בודדת שתישלח יכולה ללכת לאיבוד, אבל אם השולח ממשיך , אזי בסופו של דבר ההודעה RCVלשלוח את אותה ההודעה והמקבל ממשיך לקרוא ל
תתקבל.
ניתן לנסח זאת בצורה הפורמאלית הבאה:
in)TMT( ⋀ )at)TMT( → TMT.PAR = msg( ⋀ in)RCV(( ⇝(⃞⃟⃞⃟ ⃞⃞ ⃞⃞⃟)after)RCV( ⋀ RCV.PAR = msg(
Transmit infinitely often
The same message
Try to revive infinitely often
Successful receive
Of the desired message
Then eventually
13
)המשך(התור שמאבד הודעות
שחר דגמפרטים פורמאליים - תירגול
ננסה להסביר למה הטענה נכונה.
in)TMT( ⋀ )at)TMT( → TMT.PAR = msg( ⋀ in)RCV(( ⇝(⃞⃟⃞⃟ ⃞⃞ ⃞⃞⃟)after)RCV( ⋀ RCV.PAR = msg(
ויוצאים אין סוף פעמים או שבסופו RCV היא: או שנכנסים ל )in)RCV⃞⃟המשמעות של 5, אזי לפי טענה RCV ולא יוצאים. אם לא יוצאים מ RCVשל דבר נכנסים ל
)in)TMT⃞⃟ ולפי 4משמעות הדבר שמגיע זמן בו התור נשאר ריק לנצח אולם לפי טענה נובע כי בסופו של דבר יתווסף נתון לתור מה שסותר את ההנחה של המתנה לנצח,
אין סוף פעמים. מכיוון שגודל התור סופי ומכיוון שכל מעבר RCVכלומר נכנס ונצא מ .msg מוציא הודעה מהתור אזי בסופו של דבר גם נוציא את ההודעה RCVדרך
14
Alternating Bit Protocol
שחר דגמפרטים פורמאליים - תירגול
אנו רוצים להעביר הודעות ע"פ ערוץ רועש )שיתכן ויאבד הודעות( ולהבטיח כי כל ההודעות עברו לפי הסדר לצד השני.
לשולח יש תור של הודעות אותן הוא רוצה לשלוח.השולח ישלח את ההודעה שוב ושוב בצרוף ביט ביקורת. השולח יפסיק לשלוח את
ההודעה ויוציא אותה מהתור כאשר יקבל אישור שההודעה התקבלה )ביט הביקורת חייב להיות זהה לביט בהודעה(
0לקראת שליחת ההודעה הבאה בתור יחליף השולח את ערכו של ביט הביקורת )(0 יהפוך ל 1 ו 1יהפוך ל
למקבל יש תור של הודעות שהתקבלו.כאשר מתקבלת הודעה חדשה )ביט ביקורת שונה(, המקבל ישים אותה בתור וישלח
אישור עם ביט הביקורת שהתקבל.אותו אישור ימשיך להישלח עד שתגיע הודעה חדשה.
המקבל יתעלם מהודעות עם אותו ביט ביקורת כמו בהודעה האחרונה שהתקבלה.
15
המבנה העקרוני
שחר דגמפרטים פורמאליים - תירגול
MXMIT( הערוץ לשידור הודעות – Messages)AXMIT( הערוץ לשידור אישורים – Acknowledgment)
)שני הערוצים ממומשים ע"י תור שמאבד הודעות(
.SEND( תור הודעות לשליחה. הוספת הודעה לתור ע" קריאה ל senderלשולח ).RECEIVE( תור הודעות שהתקבלו. קריאת הודעה מהתור ע"י קריאה ל receiverלמקבל )
כל המערכת יחד בעצם מממשת תור רגיל )ללא איבוד הודעות(
16
השולח
שחר דגמפרטים פורמאליים - תירגול
Squeue – the messages that we have to sendSnum – the current sequence numberSarg – the input parameter to SENDStmtarg – the argument for the next call to
MTMT or NULL if not known yetSrcvval – the returned value by the last call to
ARCV or NULL if the value was already processed
)reminder: p ⇝ q : )p → q(( ⃞⃞ ⃞⃟
17
השולח - הסברים
שחר דגמפרטים פורמאליים - תירגול
לתור הפנימי של השולח. אנו מוסיפים הודעה לתור put היא המקבילה של 1טענה ההודעות המחכות למשלוח דרך הערוץ.
מייצגת את שליחת ההודעה דרך הערוץ הרועש. שימו לב כי בסוף התהליך 2טענה (. stmtargמאופסת ההודעה למשלוח )
( האחרון. שימו לב כי המשתנה acknowledge קוראת את ערכו של האישור )3טענה (srcvval.מאופס לפני הקריאה ומקבל ערך אחריה )
הן האפשרות היחידה לשנות את התור ומשתניו. )על כך בשקף הבא ...(5 ו 4טענות
18
)המשך(השולח – הסברים
שחר דגמפרטים פורמאליים - תירגול
בתור רגיל והיא הדרך היחידה להוסיף הודעות לתור.put היא המקבילה של 4aטענה
מטפלת במקרה בו התקבל אישור התואם להודעה האחרונה שנשלחה:4bטענה נוריד את ההודעה מהתור.1.נשנה את ספרת הביקורת2.נאפס את האישור )לסמן כי כבר התייחסנו אליו(3.
מתעלמת מאישורים לא מתאימים )אישורים להודעה שכבר נמחקה(.4cטענה
מאפשרת לקבוע את ההודעה הבאה לשידור. שימו לב כי ניתן לשנות את ההודעה 5טענה (.MTMTרק אם לא מנסים כרגע לשדר דרך הערוץ )לא בתוך
19
)המשך(השולח – הסברים
שחר דגמפרטים פורמאליים - תירגול
(.livenessטענות ה"חיות" )
לקוחה מתור רגיל ומשמעותה שאם התור לא מלא, בסופו של דבר נצא מפעולת 6טענה .SENDה
אומרת כי אם התור של ההודעות לשידור אינו ריק )תמיד( אזי בסופו של דבר 7טענה נשלח הודעה לערוץ.
.ARCV( ואומרת כי השולח ימשיך לקרוא ל 7 )דומה לטענה 8טענה
מבטיחה כי השולח יעבד את האישור9טענה
20
השולח – הוכחות
שחר דגמפרטים פורמאליים - תירגול
| ⋁ )in)MTMT( ⇝ )at)MTMT¬ שקולה לביטוי הבא: 7הוכח כי תכונת חיות מספר squeue| =0(
¬in)MTMT( ⋀ |squeue|>0 ⇝ at)MTMT( ⃞⃞ // prop #7⃞)¬in)MTMT( ⋀ |squeue|>0 ⃞⃞ → ⃞⃟at)MTMT(( // definition of ⇝⃞)¬)¬in)MTMT( ⋀ |squeue|>0( ⃞⃞ ⋁ at)MTMT(( ⃞⃟ // definition of →⃞)in)MTMT( ⋁ |squeue|>0 ¬⃞⃞ ⋁ at)MTMT(( ⃞⃟ // deMorgan⃞)in)MTMT( ⋁ ⃟|squeue|=0 ⋁ at)MTMT(( ⃞⃟ // , duality⃞ ⃞⃟⃞)¬in)MTMT( → |squeue|=0 (⃞⃟⃟ ⋁ at)MTMT((( ⃞⃟ // definition of →⃞)¬in)MTMT( → )|squeue|=0 ⃞⃟ ⋁ at)MTMT(( // p q )p⋁q(⃟ ⋁⃟⃟ =⃟⃟¬in)MTMT( ⇝ )|squeue|=0 ⋁ at)MTMT(( // definition of ⇝¬in)MTMT( ⇝ )at)MTMT( ⋁ |squeue|=0( // re-order
// the wanted expression
21
המקבל
שחר דגמפרטים פורמאליים - תירגול
rqueue - the queue of the received messages
rnum - the sequence number of the last message
rval - the returned value from RECEIVErtmtarg - the argument for the next call to
ATMT or NULL if not known yetrrcvval - the last received message or NULL
if it has already been handled
)reminder: p ⇝ q : )p → q(( ⃞⃞ ⃞⃟The reasoning for the receiver is very similar to the reasoning for the sender and it is left to the reader.
22
סיכום ביניים
שחר דגמפרטים פורמאליים - תירגול
ערוץ שידור אמין )בעצם ממש תור רגיל(
rvalrqueue
rnum
rtmtarg
rrcvval
squeue
snum
sarg
stmtarg
srcvval
23
)למערכת(פונקצית המצב
שחר דגמפרטים פורמאליים - תירגול
נגדיר את פונקציות המצב בתלות במימוש:
queue ≡ if snum ≠ rnum // the real queuethen rqueue * squeueelse rgueue * tail)squeue(
parg ≡ sarg // the argument for putgval ≡ rval // the returned value from get
שרשור התורים דורש הסבר ניפרד. על כך בשקף הבא ...
24
שרשור התורים
שחר דגמפרטים פורמאליים - תירגול
מקרים:3נבחין ב
ההודעה נשלחה )או לא( ועדיין לא התקבלה
squeue rqueue
The message
snum ≠ rnum
snum = rnum
snum ≠ rnum
ההודעה נשלחה, עברה ועדיין לא התקבל האישור
ההודעה נשלחה, עברה והתקבל האישור
1בעצם אנו מיד חוזרים למצב
new message
The message
The message
The message
25
נכונות
שחר דגמפרטים פורמאליים - תירגול
.SEND של המודול 1 בתור הרגיל נובעת ישירות מתכונה 1תכונה
.RECIEVE של המודול 1 בתור הרגיל נובעת ישירות מתכונה 2תכונה
בתור הרגיל3תכונה ראשית נשים לב כי:
בתור הרגיל יכולים לנבוע אך ורק משינויים בערכם של queueשינויים בערכו של 1.squeue, rqueue, snum, rnumבמימוש שלנו
במימוש שלנוsvalבתור הרגיל שקולים לשינויים ב parg שינויים בערכו של2.
במימוש שלנוrargבתור הרגיל שקולים לשינויים ב gval שינויים בערכו של3. SENDER של 4כל השינויים המותרים לערכים הללו במימוש שלנו מוגדרים בתכונה
RECEIVERושל
ב 4a בתור וכי תכונה 3a תואמת לתכונה SENDER ב 4aקל לראות כי תכונה RECEIVER 3 תואמת תכונהb.בתור
לא גורמות אף שינוי RECEIVER ב 4c ותכונה SENDER ב 4cברור כי תכונה במשתני התור.
לאחר שהבנו איך המערכת עובדת, עלינו להוכיח כי אכן היא שקולה לתור רגיל.
queue
send
receive
26
)המשך(נכונות
שחר דגמפרטים פורמאליים - תירגול
לא גורמות RECEIVER ב 4b ותכונה SENDER ב 4bנשאר להראות כי תכונה לשינוי בערכו של התור )ע"פ פונקצית המצב(.
מבטיחה כי השולח לא ימחק הודעה SENDER ב 4bראשית נבחין כי תכונה מבטיחה כי לא RECEIVER ב 4bמהתור בטרם עברה ליעדה ואילו תכונה
תיתוספנה לתור הודעות שכבר התקבלו. )במילים אחרות אין איבוד של הודעות ואין הכפלת הודעות(.
נשאר להראות כי לא חשוב מה המערכת מבצעת באופן פנימי, הערך של התור )החיצוני( לא משתנה
אם נחזור לפונקצית המצב שהגדרנו לפני כמה שקפים ולשלשת המקרים של התור, ניראה כי פונקצית המצב לא משנה את ערכה באף אחד מהמקרים )וזה מה
שאנו רוצים(
נשאלת השאלה האם יתכנו מקרים נוספים? הבא נבחן את כל המקרים.
queue
send
receive
27
שרשור התורים
שחר דגמפרטים פורמאליים - תירגול
נסתכל על כל המקרים ונבחן:האם הם אפשריים?1.האם התור משתנה )לפי פונקצית המצב שהגדרנו(?2.
squeue rqueue
snum ≠ rnum0
snum = rnum1
snum ≠ rnum2
snum = rnum3
snum ≠ rnum4
snum = rnum5
snum ≠ rnum6
snum = rnum7
28
)המשך(שרשור התורים
שחר דגמפרטים פורמאליים - תירגול
כבר בדקנו, ראינו שהם חוקיים ושפונקצית המצב שלנו לא 2 ו 7, 4את מקרים משנה את ערכה.
של השולח הייתה לנו 5 ריק )אחרת לפי squeue יכול להתקיים רק כש 0מקרה הודעה למשלוח( ברור שאם התור ריק הוא לא משתנה
גורר כי התקבלה הודעה, אם התקבלה הודעה יש לשלוח snum = rnum, 1מקרה אישור, אם האישור טרם עבר הינו צריכים לראות את ההודעה האחרונה בשני
היה משתנה כך snumהתורים )אבל אנחנו לא( ואם האישור עבר ערכו של שהתנאי היסודי היה מופר. בשני המקרים קבלנו סתירה כך מיקרה זה אינו אפשרי.
, מיקרה זה אינו אפשרי.1, על פי אותם נימוקים של 3מקרה
גורר כי התקבלה הודעה אבל אנו לא רואים אותה ב snum = rnum, 5מקרה rqueue המסקנה האישור להודעה כבר התקבל, אם האישור התקבל אז ה ,
SENDER היה משנה את ערכו של snumסתירה לכן מיקרה זה אינו אפשרי
לערך rnum קיבל הודעה הוא צריך לשנות את RECIEVER, אם ה 6מקרה לכן מיקרה זה אינו אפשרי.snum ≠ rnumשבהודעה, סתירה לעובדה ש
29
livenessנכונות -
שחר דגמפרטים פורמאליים - תירגול
(liveness בתור הרגיל )4נוכיח את קיום תכונה מספר תתבצע בצורה דומה(5)הוכחת תכונה
prop. 4 for the regular queue:in)PUT( ⋀ |queue| < m ⇝ after)PUT(
by prop. 6 of the sender it is sufficient to prove thatin)SEND( ⋀ |queue| < m ⇝ |squeue| < sm
We will prove this by showing that ifin)SEND( ⋀ |queue| < m ⋀ |squeue| ≥ sm )1(Holds, then eventually an element is removed from the queue
queue
send
receive
30
)המשך( livenessנכונות –
שחר דגמפרטים פורמאליים - תירגול
prop. 7 of the SENDER says that if we are not in MTMT and the queue is not empty then eventually we will be in MTMT.
prop. 4 of the lossy queue guarantee that we will exit MTMT.
Together we come to the conclusion that we will send a message infinitely often.
By definition, the lossy queue will eventually pass our message.
The RECIEVER will send the acknowledge.
With the same reasoning we can see that eventually the acknowledge will pass.
When the acknowledge passes by prop 4b the SENDER removes the message from the queue )and now |squeue| < sm(
Prove completed
31
Livenessהוכחה פורמאלית – )קריאה עצמית למתקדמים(
שחר דגמפרטים פורמאליים - תירגול
( מתקיים אבל אף הודעה 1הוכחה יותר פורמאלית תתקבל אם בדרך השלילה נניח כי )לא נמחקת מהתור
Since m = sm + rm and |squeue| ≥ sm and |queue| < m we can conclude that:
• |rqueue| < rm ⋀ snum ≠ rnum, or)2(
• |rqueue| ≤ rm ⋀ snum = rnum )3(We will show that if )2( holds eventually )3( will hold.Lets assume the opposite ))2( holds but )3( never does(
Prop 7 of the SENDER implies that whenever control is not in MTMT it will eventually be in MTMT or in other words we will be infinitely often in MTMT⃞⃟in)MTMT(
32
Livenessהמשך( – הוכחה פורמאלית(
שחר דגמפרטים פורמאליים - תירגול
According to prop 4 of the SENDER snum can change only if an element is removed from the queue. Since we assumed that no element is removed then snum remains constant.
This implies that the SENDER keeps calling MTMT with the same message< snum, head)squeue( >
Since snum never changes, according to )2( rnum never changes and |rqueue|<rm. According to prop 8 of the RECIEVER we can conclude that ⃞⃟in)MRCV(
The last 3 conclusions + the livenes property of the lossy queue bring us to the conclusion that eventually MRCV will return < snum, head)queue( > which contradicts the assumption that )3( never holds
33
Livenessהוכחה פורמאלית – )המשך(
שחר דגמפרטים פורמאליים - תירגול
So we must assume that )3( holds, but we still assume that nothing is removed from squeue.
With a similar reasoning as before we can show that this leads to the conclusion that the following holds for the MXMIT module :⃞⃟after)MRCV(
Prop 7 of the RECIEVER implies that:⃞⃟at)ATMT(
Since snum=rnum, the queue is not empty. This implies that rnum can’t change unless snum changes )but snum doesn’t change since we assume that squeue remains unchanged( and we can conclude that:⃞)at)ATMT( → ATMT.PAR=rnum(The last 3 conclusions + the livenes property of the lossy queue bring us to the conclusion that eventually ARCV returns with value rnum = snum. Now according to the SENDER spec an element must be removed from the queue, which is the required contradiction