race condition
אוקיי, הטקסט הבא הולך לדבר על race conditions בצורה בסיסית.
(וואי הרבה זמן שלא כתבתי p; )
תוכן הכתבה:
-בעצם מה זה race condition? מה זה אומר?
-מקרים במחשבים שבהם עלול להיווצר race condition
-יופי, עכשיו מה זה נותן?
-דוגמה לניצול של race condition?
-מה זה בעצם race condition?
כדי להסביר מה זה race condition (להסביר כמה זה מציק לשלב את האנגלית כל פעם פשוט אי אפשר לתאר) אני אשתמש בדוגמה שראיתי פעם...
נגיד שדני ודנה עובדים ביחד, וקובעים להיפגש בלובי, ב-12 וחצי.
אבל הם לא קבעו באיזה לובי הם הולכים להיפגש, בלובי של הקומה, או בלובי של הבניין, כמה קומות למטה.
אז דני מחכה לדנה בלובי של הקומה, ודנה מחכה לדני בלובי של הבנין, אז דנה חושבת לעצמה.. אם אני אעלה למעלה ללובי של הקומה, או שדני יהיה שם, או שהוא הבריז לה\הוא מאחר...
אבל פה הטעות הקריטית של דנה. כי בואו נתאר מצב, שדנה עולה אל דני, אבל דני יורד אל דנה...
ככה שאלא אם שניהם יורדים באותה מעלית\שניהם חולי כושר ומשתמשים רק במדרגות, הם יגיעו כל אחד ליעדו, אבל לא יפגשו אחד את השני... מה שקרה לדנה ודני, זהו מצב של race condition..(חייבים לעברת את המושג), בתכנות - כאשר מניחים שמצב מסוים מתקיים, בעוד שהוא לא חייב להמשיך להתקיים.
הזמן הקריטי, "חלון ההזדמנות" במקרה שלנו היה בערך פעמיים זמן הגעה של מעלית... כי דני יכל להיכנס למעלית עד הרגע בו דנה כמעט הגיעה לקומה, ולהפך... עוד נבחן את הזמן הקריטי בהמשך...
-הקשר של race condition לתכנות
אוקיי... עד עכשיו דיברנו בצורה כללית... עכשיו בואו נראה את הקשר של כל זה למחשבים..
במחשבים המקור של race condition הוא קצת שונה...
הרי אנחנו לא רואים את המחשב שלנו קובע להיפגש עם המחשב של יוסי בטרמינל 5, אבל שוכח לציין באיזה חלק ודברים כאלה..
אז מה זה race condition במחשבים?, העיקרון מאוד דומה... המחשב מניח הנחה מסוימת, אבל בגלל הצורה שהמעבד עובד בה, לא בטוח שההנחה הזאת עדיין נכונה.
מה זאת אומרת:
המעבד שלנו מדמה פעולה של multiproccessing(הרצת כמה תוכניות במקביל), אבל בעצם המעבד הוא מכונה סדרתית, מה שאומר שהוא מסוגל לבצע רק פעולה אחת כל פעם... אז איך הוא מריץ כמה תכניות "במקביל"? הוא
קופץ מאחת לשנייה, כאשר לכל תכנית מוקצב זמן משלה...
עכשיו, מה זה אומר בעצם? שבין שתי פקודות של תכנית מסוימת, תכנית אחרת יכלה לשנות חלק מהסביבה של התכנית, ולתכנית הראשונה אין דרך לדעת שזה קרה.
לא כל שינוי יכול לקרות, כי לדוגמה על הזיכרון של התכנית(בRAM) מגנה מערכת ההפעלה וכו'..
אז, לסיכום החלק הזה:
-בגלל צורת הפעולה של המעבד במערכות הפעלה שהן multiproccessing, יכול להיווצר מצב ששינוי מסוים בסביבה לא יאותר ע"י התכנית
זה עלול לגרום לשגיאה\פעולה לא רצויה של התכנית
-השינויים הלא מאותרים לא יכולים להתרחש בכל מקום(וטוב שכך p;), אז איפה כן?:
--בכתיבה\קריאה מההארד דיסק
--ברשתות, במקרים מסוימים
בכללי השינויים האלה מתרחשים בעיקר בקלט\פלט ממכשירים חיצוניים(למעבד, הארד דיסק נכלל בהגדרה הזאת)
-יופי, עכשיו מה זה נותן?
במבט ראשון נראה שלמרות שמצבים של race condition הם נפוצים, אי אפשר לעשות יותר מקצת בלאגן בעזרתם...
אבל אם חושבים קצת יותר אז מגלים שאפשר לעשות הרבה יותר בעזרתם...
לדוגמה:
יש לנו תכנית, שבזמן הריצה שלה שומרת כל מיני הגדרות של משתמשים בקובץ זמני, ועם סיום הריצה מוחקת אותו, אנחנו רוצים להשיג את מה שכתוב בקובץ, אבל ברגע שנסגר הלינק בין התכנית לקובץ, הקובץ נמחק! מה עושים?
נשתמש במה שלמדנו, נריץ את התכנית, ונריץ לולאה שמנסה ליצור קשר קריאה אל הקובץ.
אבל, הסיכוי שנצליח ליצור את הקשר בדיוק בין סגירת הלינק למחיקה הוא קלוש, אנחנו צריכים לעשות משהו כדי להגדיל את הסיכוי שלנו להצליח, ובגלל זה ניצור לולאה חיצונית, שתבצע את הנ"ל שוב ושוב ושוב עד להצלחה...
וככה גם אם הסיכוי הוא ממש נמוך, בזמן יחסית קצר נשיג את מה שרצינו.