1. 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. 2 הגדרה מקוצרת מפרטים פורמאליים - תירגול שחר דג שיטה להגדרת תוכניות מקביליות / מבוזרות מודול הוא אוסף של סברוטינות במקום להגדיר את הקשר בין קלט לפלט, אנו מדברים על סדרות חישוב ומגדירים אילו שינויים (מעברים) ניתן לבצע ואילו לא בצורה זו ניתן להגדיר את ההתנהגות של כל סברוטינה: ההתנהגות המותרת של הסברוטינה דברים כמו המתנה של הסברוטינה לאירועים חיצוניים (דבר שלא ניתן להגדיר במפרט ק/פ) ההתנהגות המותרת של הסביבה (למשל מה לא ניתן לשנות בזמן שהסברוטינה רצה)

3. 3 המודל החישובי מפרטים פורמאליים - תירגול שחר דג ביצוע של תוכנית מקבילית מיוצג על ידי סידרת מעברים sהוא המצב ההתחלתי, s’ הוא המצב הסופי ו α היא הפעולה שמעבירה את המערכת ממצב s למצב s’. מקביליות מיוצגת ע"י ערבוב של פעולות אטומיות מצב מהווה הקפאה (snapshot) של המערכת בנקודת זמן כלשהי. הוא יכיל את ערכי המשתנים, מצב המחסנית, מצב האוגרים ואת כל שאר משתני המערכת. (הצעד הבא מוכתב רק ע"י המצב הנוכחי ולא ע"פ המסלול בו הגענו אליו) כל החישובים הם אין סופיים. חישוב סופי מומר לחישוב אין סופי ע"י הוספת מעבר ריק מהמצב הסופי לעצמו. לא נתייחס למצב המערכת באופן ישיר אלא באמצעות פונקציות מצב (state function). נשתמש בפונקציות כדי לברר את ערכי המשתנים וכדי לברר היכן בתוכנית אנו נמצאים (at(π) כאשר π הוא מקום בתוכנית)

4. 4 המודל החישובי (הערות) מפרטים פורמאליים - תירגול שחר דג אנו לא מכירים את הפעולות האטומיות של המערכת. אנו רק יודעים מה השינויים המותרים בפונקצית המצב האבסטרקטית. אנו לא מתייחסים לפעולות שלא משנות את פונקצית המצב פעולות שמשנות את פונקצית המצב, עושות זאת רק בהתאם לתנאים בחלק של “allow changes” ולכן אנו מדברים על תכונות safety

5. 5 המפרט מפרטים פורמאליים - תירגול שחר דג מפרט של תוכנית מתואר על ידי: State function:f 1 :R 1, …, f n :R n Initial condition:I 1, …, I m Properties:P 1, …, P q THERE EXIST state functions f 1, …, f n SUCH THAT: The range of f i is R i, for each i, AND IF the initial state satisfies I 1, … I m THEN properties P 1, …, P q are satisfied throughout the execution. ומשמעותו: המפרט חייב להישמר בכל חישוב אפשרי (ביצוע) של התוכנית מה התחום של הפונקציות ? כל המצבים של התוכנית

6. 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 actions f – a state function Q – 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.) ניתן להשמיט את a אם נכון לכל פעולה אפשרית ניתן להשמיט את "when Q" אם רוצים שיהיה תקף תמיד

7. 7 safety properties (cont.) מפרטים פורמאליים - תירגול שחר דג 3.Describing when a state function can change: allowed changes to f 1 when Q 1, …, f i when Q i a 1 : R 1 → S 1... a j : R j → S j f i – state function Q i – predicate a j – set of actions R j – predicate S j – boolean function expressed with state functions For every transition In the execution, if Q i is true for state s and f i (s) ≠ f i (s’) then there is some j that: 1.α is in a j 2.R j is true for state s 3.R j is false for state s’ 4.S j is true for the pair (s, s’) If S j doesn’t include a primed version of f i, we assume it preserves it’s value

8. 8 liveness properties מפרטים פורמאליים - תירגול שחר דג מגדיר מה חייב לקרות (בסופו של דבר) נשתמש ב Linear Temporal Logic לשם הגדרת liveness. בהינתן סידרת החישוב הבאה: נגדיר כי בזמן i (כאשר התוכנית נמצאת במצב s i ): P:true at time i, if and only if it is true on state s i ⃞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. 9 מפרטים פורמאליים - תירגול שחר דג התור הרגיל (תזכורת) QUEUE PUT GET

10. 10 דוגמא מפרטים פורמאליים - תירגול שחר דג אנו רוצים לממש העברת הודעות בערוץ לא אמין (דהינו חלק מההודעות הולכות לאיבוד). אנו רוצים להבטיח כי אם הודעה מסוימת תשלח מספיק פעמים וכי אם מספיק פעמים ינסו לקרוא אותה, אזי בסופו של דבר ההודעה תעבור. ראשית נשנה את התור כך שירשה לאבד הודעות. דרושים לנו שני שינויים: 1.שינוי תכונה 3 כך שתרשה איבוד הודעות. 2.תנאי ה"חיות" המקורי לא מספיק מכיוון שהתור יכול לאבד הודעות בדיוק כשאנחנו נכנסים ל GET, לכן שינינו אותו כך שידרוש מ RCV להחזיר תשובה רק אחרי "הרבה ניסיונות"

11. 11 מפרטים פורמאליים - תירגול שחר דג התור שמאבד הודעות TMT replaces PUT RCV 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. 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. 13 התור שמאבד הודעות (המשך) מפרטים פורמאליים - תירגול שחר דג ננסה להסביר למה הטענה נכונה. (⃞⃟in(TMT) ⋀ ⃞(at(TMT) → TMT.PAR = msg) ⋀ ⃞⃟in(RCV)) ⇝ (after(RCV) ⋀ RCV.PAR = msg) המשמעות של ⃞⃟ in(RCV) היא: או שנכנסים ל RCV ויוצאים אין סוף פעמים או שבסופו של דבר נכנסים ל RCV ולא יוצאים. אם לא יוצאים מ RCV, אזי לפי טענה 5 משמעות הדבר שמגיע זמן בו התור נשאר ריק לנצח אולם לפי טענה 4 ולפי ⃞⃟ in(TMT) נובע כי בסופו של דבר יתווסף נתון לתור מה שסותר את ההנחה של המתנה לנצח, כלומר נכנס ונצא מ RCV אין סוף פעמים. מכיוון שגודל התור סופי ומכיוון שכל מעבר דרך RCV מוציא הודעה מהתור אזי בסופו של דבר גם נוציא את ההודעה msg.

14. 14 Alternating Bit Protocol מפרטים פורמאליים - תירגול שחר דג אנו רוצים להעביר הודעות ע"פ ערוץ רועש (שיתכן ויאבד הודעות) ולהבטיח כי כל ההודעות עברו לפי הסדר לצד השני. לשולח יש תור של הודעות אותן הוא רוצה לשלוח. השולח ישלח את ההודעה שוב ושוב בצרוף ביט ביקורת. השולח יפסיק לשלוח את ההודעה ויוציא אותה מהתור כאשר יקבל אישור שההודעה התקבלה (ביט הביקורת חייב להיות זהה לביט בהודעה) לקראת שליחת ההודעה הבאה בתור יחליף השולח את ערכו של ביט הביקורת (0 יהפוך ל 1 ו 1 יהפוך ל 0) למקבל יש תור של הודעות שהתקבלו. כאשר מתקבלת הודעה חדשה (ביט ביקורת שונה), המקבל ישים אותה בתור וישלח אישור עם ביט הביקורת שהתקבל. אותו אישור ימשיך להישלח עד שתגיע הודעה חדשה. המקבל יתעלם מהודעות עם אותו ביט ביקורת כמו בהודעה האחרונה שהתקבלה.

15. 15 המבנה העקרוני מפרטים פורמאליים - תירגול שחר דג MXMIT – הערוץ לשידור הודעות (Messages) AXMIT – הערוץ לשידור אישורים (Acknowledgment) (שני הערוצים ממומשים ע"י תור שמאבד הודעות) לשולח (sender) תור הודעות לשליחה. הוספת הודעה לתור ע" קריאה ל SEND. למקבל (receiver) תור הודעות שהתקבלו. קריאת הודעה מהתור ע"י קריאה ל RECEIVE. כל המערכת יחד בעצם מממשת תור רגיל (ללא איבוד הודעות)

16. 16 השולח מפרטים פורמאליים - תירגול שחר דג Squeue– the messages that we have to send Snum– the current sequence number Sarg– the input parameter to SEND Stmtarg– the argument for the next call to MTMT or NULL if not known yet Srcvval– the returned value by the last call to ARCV or NULL if the value was already processed (reminder: p ⇝ q : ⃞ (p → ⃟ q))

17. 17 השולח - הסברים מפרטים פורמאליים - תירגול שחר דג טענה 1 היא המקבילה של put לתור הפנימי של השולח. אנו מוסיפים הודעה לתור ההודעות המחכות למשלוח דרך הערוץ. טענה 2 מייצגת את שליחת ההודעה דרך הערוץ הרועש. שימו לב כי בסוף התהליך מאופסת ההודעה למשלוח (stmtarg). טענה 3 קוראת את ערכו של האישור (acknowledge) האחרון. שימו לב כי המשתנה (srcvval) מאופס לפני הקריאה ומקבל ערך אחריה. טענות 4 ו 5 הן האפשרות היחידה לשנות את התור ומשתניו. (על כך בשקף הבא...)

18. 18 השולח – הסברים (המשך) מפרטים פורמאליים - תירגול שחר דג טענה 4a היא המקבילה של put בתור רגיל והיא הדרך היחידה להוסיף הודעות לתור. טענה 4b מטפלת במקרה בו התקבל אישור התואם להודעה האחרונה שנשלחה: 1.נוריד את ההודעה מהתור. 2.נשנה את ספרת הביקורת 3.נאפס את האישור (לסמן כי כבר התייחסנו אליו) טענה 4c מתעלמת מאישורים לא מתאימים (אישורים להודעה שכבר נמחקה). טענה 5 מאפשרת לקבוע את ההודעה הבאה לשידור. שימו לב כי ניתן לשנות את ההודעה רק אם לא מנסים כרגע לשדר דרך הערוץ (לא בתוך MTMT).

19. 19 השולח – הסברים (המשך) מפרטים פורמאליים - תירגול שחר דג טענות ה"חיות" (liveness). טענה 6 לקוחה מתור רגיל ומשמעותה שאם התור לא מלא, בסופו של דבר נצא מפעולת ה SEND. טענה 7 אומרת כי אם התור של ההודעות לשידור אינו ריק (תמיד) אזי בסופו של דבר נשלח הודעה לערוץ. טענה 8 (דומה לטענה 7) ואומרת כי השולח ימשיך לקרוא ל ARCV. טענה 9 מבטיחה כי השולח יעבד את האישור

20. 20 השולח – הוכחות מפרטים פורמאליים - תירגול שחר דג הוכח כי תכונת חיות מספר 7 שקולה לביטוי הבא : ¬in(MTMT) ⇝ (at(MTMT) ⋁ |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. 21 המקבל מפרטים פורמאליים - תירגול שחר דג rqueue- the queue of the received messages rnum- the sequence number of the last message rval- the returned value from RECEIVE rtmtarg- the argument for the next call to ATMT or NULL if not known yet rrcvval- 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. 22 סיכום ביניים מפרטים פורמאליים - תירגול שחר דג ערוץ שידור אמין (בעצם ממש תור רגיל) rval rqueue rnum rtmtarg rrcvval squeue snum sarg stmtarg srcvval

23. 23 פונקצית המצב (למערכת) מפרטים פורמאליים - תירגול שחר דג נגדיר את פונקציות המצב בתלות במימוש: queue ≡if snum ≠ rnum// the real queue then rqueue * squeue else rgueue * tail(squeue) parg≡sarg// the argument for put gval≡rval// the returned value from get שרשור התורים דורש הסבר ניפרד. על כך בשקף הבא...

24. 24 שרשור התורים מפרטים פורמאליים - תירגול שחר דג נבחין ב 3 מקרים: ההודעה נשלחה (או לא) ועדיין לא התקבלה squeuerqueue The message snum ≠ rnum snum = rnum snum ≠ rnum ההודעה נשלחה, עברה ועדיין לא התקבל האישור ההודעה נשלחה, עברה והתקבל האישור בעצם אנו מיד חוזרים למצב 1 new message The message

25. 25 נכונות מפרטים פורמאליים - תירגול שחר דג תכונה 1 בתור הרגיל נובעת ישירות מתכונה 1 של המודול SEND. תכונה 2 בתור הרגיל נובעת ישירות מתכונה 1 של המודול RECIEVE. תכונה 3 בתור הרגיל ראשית נשים לב כי: 1.שינויים בערכו של queue בתור הרגיל יכולים לנבוע אך ורק משינויים בערכם של squeue, rqueue, snum, rnum במימוש שלנו 2.שינויים בערכו של parg בתור הרגיל שקולים לשינויים ב sval במימוש שלנו 3.שינויים בערכו של gval בתור הרגיל שקולים לשינויים ב rarg במימוש שלנו כל השינויים המותרים לערכים הללו במימוש שלנו מוגדרים בתכונה 4 של SENDER ושל RECEIVER קל לראות כי תכונה 4a ב SENDER תואמת לתכונה 3a בתור וכי תכונה 4a ב RECEIVER תואמת תכונה 3b בתור. ברור כי תכונה 4c ב SENDER ותכונה 4c ב RECEIVER לא גורמות אף שינוי במשתני התור. לאחר שהבנו איך המערכת עובדת, עלינו להוכיח כי אכן היא שקולה לתור רגיל. queue send receive

26. 26 נכונות (המשך) מפרטים פורמאליים - תירגול שחר דג נשאר להראות כי תכונה 4b ב SENDER ותכונה 4b ב RECEIVER לא גורמות לשינוי בערכו של התור (ע"פ פונקצית המצב). ראשית נבחין כי תכונה 4b ב SENDER מבטיחה כי השולח לא ימחק הודעה מהתור בטרם עברה ליעדה ואילו תכונה 4b ב RECEIVER מבטיחה כי לא תיתוספנה לתור הודעות שכבר התקבלו. (במילים אחרות אין איבוד של הודעות ואין הכפלת הודעות). נשאר להראות כי לא חשוב מה המערכת מבצעת באופן פנימי, הערך של התור (החיצוני) לא משתנה אם נחזור לפונקצית המצב שהגדרנו לפני כמה שקפים ולשלשת המקרים של התור, ניראה כי פונקצית המצב לא משנה את ערכה באף אחד מהמקרים (וזה מה שאנו רוצים) נשאלת השאלה האם יתכנו מקרים נוספים? הבא נבחן את כל המקרים. queue send receive

27. 27 שרשור התורים מפרטים פורמאליים - תירגול שחר דג נסתכל על כל המקרים ונבחן: 1.האם הם אפשריים? 2.האם התור משתנה (לפי פונקצית המצב שהגדרנו)? squeue rqueue snum ≠ rnum0 snum = rnum1 snum ≠ rnum2 snum = rnum3 snum ≠ rnum4 snum = rnum5 snum ≠ rnum6 snum = rnum7

28. 28 שרשור התורים (המשך) מפרטים פורמאליים - תירגול שחר דג את מקרים 4, 7 ו 2 כבר בדקנו, ראינו שהם חוקיים ושפונקצית המצב שלנו לא משנה את ערכה. מקרה 0 יכול להתקיים רק כש squeue ריק (אחרת לפי 5 של השולח הייתה לנו הודעה למשלוח) ברור שאם התור ריק הוא לא משתנה מקרה 1, snum = rnum גורר כי התקבלה הודעה, אם התקבלה הודעה יש לשלוח אישור, אם האישור טרם עבר הינו צריכים לראות את ההודעה האחרונה בשני התורים (אבל אנחנו לא) ואם האישור עבר ערכו של snum היה משתנה כך שהתנאי היסודי היה מופר. בשני המקרים קבלנו סתירה כך מיקרה זה אינו אפשרי. מקרה 3, על פי אותם נימוקים של 1, מיקרה זה אינו אפשרי. מקרה 5, snum = rnum גורר כי התקבלה הודעה אבל אנו לא רואים אותה ב rqueue, המסקנה האישור להודעה כבר התקבל, אם האישור התקבל אז ה SENDER היה משנה את ערכו של snum סתירה לכן מיקרה זה אינו אפשרי מקרה 6, אם ה RECIEVER קיבל הודעה הוא צריך לשנות את rnum לערך שבהודעה, סתירה לעובדה ש snum ≠ rnum לכן מיקרה זה אינו אפשרי.

29. 29 נכונות - liveness מפרטים פורמאליים - תירגול שחר דג נוכיח את קיום תכונה מספר 4 בתור הרגיל (liveness) (הוכחת תכונה 5 תתבצע בצורה דומה) prop. 4 for the regular queue: in(PUT) ⋀ |queue| < m ⇝ after(PUT) by prop. 6 of the sender it is sufficient to prove that in(SEND) ⋀ |queue| < m ⇝ |squeue| < sm We will prove this by showing that if in(SEND) ⋀ |queue| < m ⋀ |squeue| ≥ sm (1) Holds, then eventually an element is removed from the queue queue send receive

30. 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. 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. 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 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 which contradicts the assumption that (3) never holds

33. 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