נובמבר סנכרון תהליכים וחוטים Process and Thread Synchronization חלק ראשון

נובמבר עמוד נושאים מוטיבציה הגדרות פיתרון כללי מנעולים ותמיכתם בחומרה

נובמבר עמוד מוטיבציה הנחות –קריאה/כתיבה של משתנה היא אטומית –פעולה אריתמטית על המשתנה אינה אטומית מי זוכה?לפעמים A ולפעמים B האם תמיד יש זוכה?לא האם שניהם עשויים לזכות?כן, כאשר הפקודה kill אסינכרונית int c = 0; // Global variable Thread A: while (c < 10) c = c + 1; kill B; print “A wins”; Thread B: while (c > -10) c = c - 1; kill A; print “B wins”;

נובמבר עמוד בעית יצרן/צרכן הגדרות –שני חוטים (יצרן וצרכן) רצים באותו מרחב זיכרון –מערך חסום (מעגלי) מכיל את העצמים המיוצרים –ליצרן מצביע (pp) למקום הפנוי הבא במערך –לצרכן מצביע (cp) למקום הבא המכיל את העצם המוכן הבא –מספר העצמים המוכנים הוא c 0n-1 cppp c

נובמבר עמוד בעית יצרן/צרכן (המשך) בעיות –עדכון בו זמנית (לא מוגן) של c –לכן ערכו של c יכול להיות גבוה (נמוך) מן הערך הנכון int c = 0; // Global variable Producer: repeat while (c>=n) nop; buf[pp] = new item; pp = (pp+1) mod n; c = c + 1; until false; Consumer: repeat while (c<1) nop; consume buf[cp]; cp = (cp+1) mod n; c = c - 1; until false;

נובמבר עמוד בעית החלב את/ה: מסתכל במקרר הולך לסופר קונה חלב חוזר הביתה מכניס חלב למקרר שותף: מסתכל במקרר הולך לסופר קונה חלב חוזר הביתה מכניס חלב למקרר בעיה: יותר מדי חלב!

נובמבר עמוד בעית החלב פיתרון 1  פיתרון: להשאיר פיתקה בעיה: כל אחד קפץ לחדר לכתוב פתק ולא שם לב לכך שהשני השאיר פתק מסתכל במקרר אם אין חלב אם אין פתקה השאר פתקה קנה חלב הורד פתקה

נובמבר עמוד בעית החלב פיתרון 2  פיתרון: לאחר השארת הפיתקה, בודקים האם גם השותף השאיר פיתקה בעיה: קיים תסריט בו אף אחד לא יקנה חלב! Thread A: leave note A if (no note B) then if (no milk) then buy milk remove note A Thread B: leave note B if (no note A) then if (no milk) then buy milk remove note B

נובמבר עמוד בעית החלב פיתרון 3  פיתרון: שבירת הסימטריה במקרה של "תחרות" (שניהם משאירים פתק בו זמנית), A יקנה חלב! חסרונות –רק לשני תהליכים –לא הוגן Thread A: leave note A X:while (note B) do nop if (no milk) then buy milk remove note A Thread B: leave note B Y:if (no note A) then if (no milk) then buy milk remove note B

נובמבר עמוד הגדרות בגים בתכניות מקביליות –בד"כ התכנית עובדת נכון –קיים תסריט בו התכנית לא עובדת נכון לרוב בגלל שבירה איזושהי הנחת אטומיות שאינה מתקיימת מרוץ (Race Condition) –גישות בו-זמניות (כולל כתיבה) לאותו משתנה גלובלי בדוגמת בעית החלב –השארת פיתקה –בדיקה האם השותף השאיר פיתקה

נובמבר עמוד הגדרות (המשך) מניעה הדדית – mutual exclusion –מנגנונים המבטיחים שרק חוט אחד מבצע סדרת פעולות מסוימות בזמן נתון אטומיות ביחס לחוטים אחרים קטע קריטי – critical section –קטע קוד שרק חוט אחד מבצע בזמן נתון לא קריטי יציאה קריטי

נובמבר עמוד הגדרות (המשך) אטומיות – Atomicity –בביצוע סדרת פקודות ע"י חוט אחד,חוטים אחרים אינם יכולים לראות תוצאות חלקיות - סדרת הפקודות נראית כמו פעולה אחת שאיננה ניתנת לחלוקה ("פעולה אטומית") –ניתן להשיג בעזרת מנגנון של מניעה הדדית דוגמא –העברת כספים מחשבון לחשבון –לא נאפשר לחוטים אחרים לראות מצב בו הכסף נמשך מחשבון א' אך לא הגיע לחשבון ב' Thread A: account1:= account1 – sum; account2:= account2 + sum; Thread B: if (account1+account2<min) then …

נובמבר עמוד תכונות של פתרון לבעיית הקטע הקריטי חובה –רק חוט אחד בקטע קריטי (מניעה הדדית) –אם יש בקשות להיכנס לקטע קריטי, אזי חוט אחד ייכנס (אין קיפאון – deadlock) רצוי –חוט המבקש להיכנס לקטע קריטי בסופו של דבר יצליח (אין הרעבה – starvation) –עבור כל זוג חוטים, אם הם יתחרו n פעמים להיכנס לקטע קריטי, הם יזכו מספר דומה של פעמים (fairness)

נובמבר עמוד Thread i: initially number[i]=0 number[i]=max{number[1],…,number[n]}+1; for all j  i do wait until number[j]=0 or (number[j]>number[i]) critical section number[i]=0 // Exit critical section אלגוריתם קופת חולים (bakery) לפיתרון בעית הקטע הקריטי (1) שימוש במספרים –חוט נכנס לוקח מספר –חוט שמספרו הקטן ביותר נכנס לקטע הקריטי ניסיון ראשון

נובמבר עמוד אלגוריתם קופת חולים (bakery) לפיתרון בעית מניעה הדדית (1) בעיה –חוט i ו-j קוראים את המערך בו זמנית –שניהם "בוחרים" את אותו מספר קיפאון!

נובמבר עמוד אלגוריתם קופת חולים (bakery) לפיתרון בעית מניעה הדדית (2) נשתמש במס' הזהות של התהליך כדי לשבור סימטריה Thread i: initially number[i]=0 number[i]=max{number[1],…,number[n]}+1; for all j  i do wait until number[j]=0 or ()number[j],j)>(number[i],i)) // lexicographical // comparison critical section number[i]=0 // Exit critical section

נובמבר עמוד אלגוריתם קופת חולים (bakery) לפיתרון בעית מניעה הדדית (2) בעיה –חוט i ו-j קוראים את המערך בו זמנית (i>j) –חוט i כותב את המספר, בודק את ערכו כנגד number ונכנס לקטע הקריטי (number[j] עדיין 0!) –חוט j ממשיך וגם הוא נכנס לקטע הקריטי! אין מניעה הדדית! –התהליך עם מספר זהות גבוה (i) מזדרז להיכנס לקטע הקריטי לפני ש-j הספיק לכתוב את number[j]

נובמבר עמוד אלגוריתם קופת חולים (bakery) לפיתרון בעית מניעה הדדית (3) נוודא שאין חוטים באמצע בחירת מספר לפני ביצוע ההשוואות Thread i: initially number[i]=0 choosing[i]=true number[i]=max{number[1],…,number[n]}+1; choosing[i]=false for all j  i do wait until choosing[j]=false for all j  i do wait until number[j]=0 or ()number[j],j)>(number[i],i)) critical section number[i]=0 // Exit critical section

נובמבר עמוד אלגוריתם קופת חולים (bakery) לפיתרון בעית מניעה הדדית (3) אין הרעבה (ולכן אין קיפאון) והפתרון הוגן –הוכחה בתרגול פיתרון מסורבל –הרבה פעולות, הרבה משתנים הפיתרון לא יעבוד בסביבות מרובות מעבדים –Out of order execution קיימים אלגוריתמים אחרים בהמשך נלמד על פתרונות אחרים

נובמבר עמוד מנעולים (locks) מבטיחים גישה בלעדית למידע באמצעות שתי פונקציות –lock_acquire(lock) – פעולה חוסמת (אם המנעול תפוס) –lock_release (lock) – משחרר את המנעול

נובמבר עמוד מנעולים (locks) – דוגמא דוגמא – בעית יצרן/צרכן האם ניתן לוותר על הגנה של קריאת c ב-?while –מה קורה במקרה של יותר מצרכן אחד? Producer: repeat while (c>n) nop; buf[pp] = new item; pp = (pp+1) mod n; lock_acquire(c_lock) c = c + 1; lock_release(c_lock) until false; Consumer: repeat while (c<1) nop; consume buf[cp]; cp = (cp+1) mod n; lock_acquire(c_lock) c = c - 1; lock_release(c_lock) until false;

נובמבר עמוד lock_release(L): disableInterrupts() L := FREE enableInterrupts() מימוש מנעולים אטומיות –מובטחת ע"י חסימת פסיקות Busy wait –ניתן למנוע ע"י ניהול תור החוטים המחכים למה חשוב לאפשר פסיקות בתוך הלולאה? ומה קורה במערכות מרובות מעבדים? –חסימת פסיקות אינה מבטיחה אטומיות... –דורש תמיכה מהחומרה לפקודות "חזקות" יותר lock_acquire(L): disableInterrupts() while L  FREE do enableInterrupts() disableInterrupts() L := BUSY enableInterrupts()

נובמבר עמוד מימוש מנעולים תמיכת חומרה test&set test&set(boolvar) –כתוב ערך true והחזר ערך קודם –L = false – מנעול פנוי –L = true – מנעול תפוס lock_release(L): L := false lock_acquire(L): while test&set(L) do nop

נובמבר עמוד מימוש מנעולים תמיכת חומרה compare&swap compare&swap(mem, r1, r2) –אם בזיכרון (mem) ערך זהה לרגיסטר r1, כתוב ערך r2 והחזר הצלחה –אחרת החזר ערך כישלון ניתן לממש מונה אטומי lock_acquire(L): r1 = false r2 = true while not compare&swap(L, r1, r2)) do nop lock_release(L): L := false

נובמבר עמוד מימוש מנעולים מודרני load-linked & store conditional ממומש ברוב הארכיטקטורות החדישות –Compaq’s Alpha, IBM’s PowerPC, MIPS4000 צמד פקודות –LL(mem) – קרא את ערך הזיכרון –SC(mem, val) – אם לא היתה כתיבה ל-mem מאז ה- LL(mem) האחרון, כתוב ערך val והחזר הצלחה (אחרת כשלון) יותר כח מאשר ל-compare&swap –ניתן לזהות כתיבות עוקבות של אותו ערך

נובמבר עמוד מימוש מנעולים load-linked & store conditional lock_acquire(L): success = false repeat LL(L) if not L then success = SC(L, true) until success lock_release(L): L := false

נובמבר עמוד load-linked & store conditional מתי חשוב לזהות כתיבות עוקבות של אותו ערך? –ברשימה מקושרת, הוצאת האיבר הראשון remove_first(head): element = NULL A:if head  NULL then LL(head) next_head = head->next element = head if not SC(head, next_head) goto A; return element