1 / 23

Principles of Structure of Operating Systems עקרונות מבנה מערכות הפעלה

Principles of Structure of Operating Systems עקרונות מבנה מערכות הפעלה. בעיית הקטע הקריטי- פתרונות בחומרה ובמ"ה. בעיות בפתרונות תוכנה לקטע קריטי. א.מורכבות קשים להבנה, קל לטעות בייחוד עבור יותר משני תהליכים ב. מבצעים busy wait ממתינים בלולאה אינסופית עד שתנאי מתקיים: while (flag) ;

brett-gould
Download Presentation

Principles of Structure of Operating Systems עקרונות מבנה מערכות הפעלה

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Principles of Structure of Operating Systemsעקרונות מבנה מערכות הפעלה בעיית הקטע הקריטי- פתרונות בחומרה ובמ"ה

  2. בעיות בפתרונות תוכנה לקטע קריטי א.מורכבות • קשים להבנה, קל לטעות • בייחוד עבור יותר משני תהליכים ב. מבצעים busy wait • ממתינים בלולאה אינסופית עד שתנאי מתקיים: while (flag) ; • flag הוא spin lock • צורך CPU • priority inversion עשוי לגרום ל deadlock במציאות, נעזרים בפתרונות הנעזרים בחמרה

  3. פתרונות חומרה מבוא • בעיית הקטע הקריטי יכולה להיפתר בקלות במערכת עם מעבד אחד, אם לא נרשה לקבל interrupt ברגע שמשתנה משותף מעודכן. בעניין זה, נוכל להיות בטוחים שסידרת ההוראות תבוצע בסדר הנכון ללא הפרעות. אף הוראה אחרת לא תרוץ, וכך לא יתבצעו שינויים לא צפויים במשתנה המשותף. • הבעיה היא שפתרון זה לא אפשרי במערכת multiprocessor. מניעת interrupt-ים במערכת multiprocessor צורכת זמן, כאשר מעבירים את ההודעה בכל המעבדים. העברת ההודעה בכל כניסה לקטע קריטי תגרום להפחתת יעילות המערכת. בנוסף, יש לקחת בחשבון את ההשפעה שתהייה על שעות המערכת, אם השעון מעודכן בעזרת interrupt-ים. • לכן מכונות רבות מספקות הוראות חומרה מיוחדות המאפשרות לנו או לבדוק ולעדכן תוכן של מילה, או להחליף תוכן שתי מילים בצורה אטומית. נוכל להשתמש בהוראות מיוחדות אלו בכדי לפתור את בעיית הקטע הקריטי בצורה פשוטה מאוד.

  4. פעולת Test-and-Set-Lock הגדרה : פעולה המאפשרות לנו לבדוק ולעדכן תוכן של משתנה, או להחליף תוכן בין שני משתנים בצורה אטומית. כלומר, ההוראה מתבצעת כיחידה אחת שלא ניתנת להפרעה ע"י interrupt-ים. לכן, אם שתי הוראות Test-and-Set יופעלו, הן ירוצו אחת אחרי השנייה בסדר כלשהו.

  5. מימוש ההוראה Test-and-Set-Lock int TaSL(int *target) { int save = *target; *target = 1; return save; }

  6. אם המכונה תומכת בהוראה Test-and-Set, אזי ניתן לממש mutual exclusion ע"י הצהרת משתנה בוליאני בשם lock אשר יאותחל ל-false. קוד התהליך יראה בצורה הבאה: • אתחול:lock:=0 do { whileTaSL ( &lock) ; critical section lock := 0; remainder section } while true;

  7. הסבר • ה thread הראשון שנכנס הופך את lock ל-true ונכנס אל CS, ולכן אף thread לא יוכל להיכנס עד שהוא לא יסיים עם CS ויבצע lock:=false וברגע שתתבצע שורה זו אז ה-thread הראשון שיגיע אל הלולאה כאשר lock==false ייכנס אל CS. • יתרון: פעולה אטומית • חסרונות:1. חסימה מעסיקה. 2. סדר כניסה לא ידוע.

  8. מה קורה ברמת החומרה? : enter_region TaSL register, lock | copy lock to register and set to 1 cmp register, #0 | was flag zero ? jnz enter_region | if non-zero lock was set, loop ret :leave_region mov lock, #0 | store 0 in lock ret

  9. פתרונות בעזרת פעולות אטומיות בחמרה:סיכום • יתרונות: • פשוטים • תומכים במספר כלשהו של תהליכים • אטומית • חסרונות: • busy waiting + priority inversion • שתיתכן הרעבה, • לא portable בין חומרות שונות, ולכן לא מתאימים ברמת משתמש • לאפליקציות צרכי סנכרון נוספים מעבר לקטעים קריטיים, למשל סדר בין פעולות

  10. פתרון קטע קריטי ברמת מע' הפעלה לאור החסרונות שהוצגו בפתרונות ברמת תוכנה וחומרה נרצה דרך פתרון אשר : • שתהיה קלה לשימוש • פתרונות פשוטים ברמת התכניתן • שתספק ממשק אחיד מעל חמרה כלשהי • תכנת משתמש portable • תתמוך בצרכי סנכרון שונים • המימוש של אבסטרקציה זו • יוכל לנצל תמיכת חומרה כאשר היא קיימת (מוחבא) • יוכל למנוע busy wait ו priority inversion

  11. Semaphores מה זה סמפור ?? סמפור הגדרה : Semaphore הוא משתנה מסוג integer, אשר פרט לשלב בו הוא מאותחל, ניתן לגשת אליו רק דרך שתי פעולות אטומיות: wait ו-signal. • אבסטרקציה שמע"ה מספקת וגם מנצלת

  12. הגדרת הפעולות wait ו-signal : wait : wait(S): { while(S ≤ 0); //המתנה לכניסה אל הקטע הקריטי S--; } Signal : Signal(S): { S++; //יציאה מהקטע הקריטי ואיתות על כך } • שימו לב: זו הגדרה, לא מימוש • נקרא גם "סמפור סופר" counting semaphore

  13. הערות נוספות • עדכון ערכו של ה-semaphore בהוראות ה-wait ו-signal חייב להתבצע באופן שאינו ניתן לחלוקה. כלומר, כאשר תהליך אחד מעדכן את ערך ה-semaphore, אף תהליך אחר לא יכול לעדכן בו-זמנית את אותו semaphore. בנוסף, במקרה של wait(S), הבדיקה האם S<=0 ולאחר מכן העדכון S:= S – 1, חייבים גם כן לרוץ ללא הפרעות.

  14. בעיה בהגדרה שלנו והפתרון שלה • אחד החסרונות בלולאות ה-while שהגדרנו עד כה הוא השימוש ב-busy waiting. כאשר תהליך רוצה להיכנס לקטע הקריטי והוא צריך להמתין הוא מבצע לולאה בתור ה-entry code. ללולאה זו יוצרת בעיה במערכות multiprogramming, בהן מעבד אחד מתחלק בין מספר תהליכים. Busy waiting מבזבז משאבים של ה-CPU, בזמן שתהליכים אחרים היו יכולים להשתמש ב-CPU בצורה יעילה יותר. • כדי להתגבר על הצורך של busy waiting נעדכן את הגדרת ההוראות wait ו-signal. כאשר תהליך מריץ את הוראת ה-wait ומגלה שערך ה-semaphore שלילי, הוא יהיה חייב לחכות. אבל, במקום להשתמש ב-busy waiting, התהליך יחסום (block) את עצמו.

  15. הגדרת הפעולות wait ו-signal משופרת: wait : wait(S): { if (S ≤ 0) block; S--; } Signal : signal(S): { S++; if (exists blocked process) unblock a process; }

  16. דוגמא לשימוש ב-semaphore עבור קטע קריטי בשימוש של N תהליכים • ניתן להשתמש ב- semaphoresכדי להתמודד עם בעיית הקטע הקריטי עבור n תהליכים. n התהליכים חולקים semaphore בשם mutex המאותחל ל-1. • כל תהליך מאורגן בצורה הבאה: repeat wait(mutex); critical section signal(mutex); remainder section untilfalse

  17. משמעות הפעולותblock ו- unblock בהגדרה שלנו בהקשר לתהליכים שלמדנו • פעולת החסימה ממקמת את התהליך בתור ה-blocking המקושר ל-semaphore, וסטאטוס התהליך הופך ל-blocked. • תהליך שחסום יותחל מחדש כאשר תהליך אחר יריץ הוראת signal. התהליך יותחל מחדש בעזרת הוראת wakeup, אשר משנה את סטאטוס התהליך מ- blocked ל-ready, וכך ממוקם התהליך שוב בתור ה-ready.

  18. ההשלכות הנובעות מהמשמעויות שהצגנו • כדי לממש semaphore תחת הגדרות אלו, נגדיר את ה- semaphore בצורת מבנה המורכב מ- • משתנה value מטיפוס integer • רשימה/תור List של תהליכים ממתינים • מצביעים ל PCBs הגדרת טיפוס המבנה תהיה : typedef struct semaphore { int value; LIST List; } * LIST הוא טיפוס רשימת תהליכים.

  19. הסבר • לכל semaphore יש ערך מספרי ורשימת תהליכים. כאשר תהליך חייב לחכות ל- semaphore הוא מתווסף לרשימת התהליכים. הוראת signal מסירה תהליך אחד מרשימת התהליכים הממתינים, ומעירה אותו.

  20. מימוש מבנה סמפורים • נגדיר משתנה ספור S מטיפוס המבנה semaphore בצורה הבאה : struct semaphoreS; • נאתחל את השדה value בערך 1 s.value=1;

  21. הגדרת הפעולות wait ו-signal למבנה סמפורי wait : wait(S): if (s.value < 0) { add me to S.List; block; } s.value--; הסבר : אם ערך הסמפור שלילי אז נוסיף אותו אל הרשימה ונחסום אותו (block) Signal : segnal(S): s.value++; if (s.value ≤ 0) { remove a process P from S.List; wake-up P; } הסבר : אם עדיין  0 למרות שהעלנו ב 1, זה אומר שעדיין יש ממתינים ולכן נסיר process מרשימת ההמתנה

  22. הסבר נוסף • הוראת block משהה את התהליך. הוראת wakeup מחדשת את ריצת התהליך שנחסם. שתי הוראות אלו מסופקות ע"י מערכת ההפעלה כ-system call בסיסיות.

  23. סיכום • סמפור • אבסטרקציה נוחה למתכנת • פתרון מיידי לבעיית הקטע הקריטי • שימושי עבור בעיות סינכרון נוספות • לא תלוי חומרה (האבסטרקציה לא תלוית חומרה) • מימוש • מונע busy wait • מנצל פעולות אטומיות בחמרה (כאשר קיימות)

More Related