1 מפרטים פורמאליים תירגול מספר 10 Lamport Based on the paper: “specifying concurrent program modules” by Leslie Lamport (ACM Transaction on programming.

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( ⃞⃞ ⃞⃟

9שחר דגמפרטים פורמאליים - תירגול

התור הרגיל)תזכורת(

QUEUE

PUT

GET

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