הכנה למבחן מערכות הפעלה

עבור אילו פעולות כדאי להשתמש ב DMA? נמק והסבר.

DMA= Dynamic Memory Acceses. הDMA בא להחליף את המעבד. אמרנו שכל פעולה של לקיחה של מידע מהבפאר הלוקאלי של device controller צריכה לעבור דרך המעבד, ז"א המעבד לוקח את הנתון ושם אותו בזיכרון, או לחילופין המעבד לוקח מהזכרון ערך ושם אותו בבאפר הלוקאלי של הdevice controller, בשביל שdevice controller יוכל לבצע את העבודה שלו, למשל כתיבה לדיסק/ הצגה למסך וכו'. הDMA בא בעצם לעקוף את המנגנון הזה ולאפשר גישה לזכירון עבור הdevice controller ולהפך, לאפשר גישה ישירה מהזכרון לdevice controller. ז"א שהdevice controller במקום שכל פעם הוא יעשה interrupt על כל בית שהוא קורא מהדיסק והמעבד יצטרך לעצור את מה שהוא עושה ולהעביר את הנתון הזה לזיכרון, במקום זה הdevice controller בצורה ישירה יעביר דרך ה bus את הנתונים לזכירון ואחת לכמה זמן הוא יספר למעבד באמצעות interrupt שהוא העביר בלוק גדול של נתונים לזכירון, או להפך שהוא קרא בלוק גדול של נתונים מהזיכרון למעבד. באיזה פעולות כדאי להשתמש בDMA ובאיזה פעולות לא כדאי להשתמש ? כשאני רוצה להעביר המון מידע אני לא רוצה שעבור כל בית יהיה לי interrupt המעבד יתעורר ויטפל. במקומות שבהן על כל פריט מידע קטן ככל שיהיה, אני רוצה שהמערכת תתיחס לזה, אני לא ארצה להשתמש בDMA למשל מקלדת ועכבר. כי אז הdevice controller היה אוסף הרבה מאוד הקלקות בבאפר הלוקאלי שלו ומעביר אותם לזכירון ואחת ל1000/ 2000 הקלקות היה מודיע באמצעות interrupt למעבד ואז המעבד היה מטפל במכה בכל ההקלקות. זה היה ניראה מקוטע. זה היה מופיע אחת לכמה דקות זה היה נוראי. תשובה רשימית וסופית: כאשר נרצה להעביר כמות גדולה של מידע בין הזיכרון והdevice. המנגנון חוסך את הצורך לערב את ה CPU בתהליך, וכך מתקבלת העברה מהירה שבמהלכה הCPU יכול לבצע דברים אחרים במקביל.

רשום את 4 התנאים ההכרחים לדדלוק והסברה בקצרה כל אחד מהם.

-mutual exclusion- רק תהליך בו זמנית יכול להשתמש במופע של משאב. לדוגמא אם יש תהליך שמשתמש במשאב של מדפסת, אף תהליך אחר לא יכול להשתמש בו, בו זמנית. -hold and wait- כדי שיווצר דדלוק, חייב להיות תהליך שמחזיק לפחות מופע אחד של משאב, וממתין לקבל משאב (או משאבים) נוספים שמוחזקים ע"י תהליכים אחרים. - No preemption- שחרור משאב אפשרי רק בצורה התנדבותית ע"י התהליך שמחזיר אותו כרגע, לאחר שהתהליך סיים את המשימה. כלומר, אין מצב שבו תהליך ישחרר עצמאית את המשאב אלא רק כשיסיים להשתמש בו. - Circular wait- יש סט תהליכים P0..Pn שכולם במצב של waiting והם ממתינים לתהליכים אחרים מהסט שישחררו משאבים- וההמתנה היא מעגלית- P0 ממתין לP1, P1 ממתין לP2 וכך הלאה עד שPn ממתין לP0. המעגל הזה הוא קריטי ליצרת דדלוק.

להלן הצעה למימוש MLFQ: multi level feedback Queue. המחשה של ההצעה: תור ראשון quantum=20 תור מתחתיו quantum -10 תור תחתון FCFS הסבר: על פי הצעה זו, כל תהליך חדש שנכנס לready queue יגיע לתור הראשון ויקבל בתורו 20 יחידות זמן מעבד. במידה ולא יסיים את הburst שלו יעבור לתור השני ויקבל 10 יחידות זמן מעבד, במידה ועדיין לא יסיים את הburst שלו יעבור לתור השלישי וישובץ לפי FCFS. כל רמה בMLFQ תקבל זמן מעבד רק אם התורים שמעליה ריקים. כלומר אם הburst שלי קטן מ20 אני אסיים בתור הראשון, ואצא ממנו, אם הburst שלי גדול מ20, אני אעבור לתור השני, שם אקבל זמן מעבד של 10 יחידות, אם סיימתי (ביקשתי פחות מ30) אז אני אצא מהמערכת, אם לא סיימתי (ביקשתי יותר מ30) אכנס לתור האחרון שמנוהל לפי סדר הכניסה. בנוסף, אומרים לנו שכל רמה תקבל זמן רק אם התורים שמעליה ריקים, ז"א שאם יש לנו תהליכים בתור העליון שמחכים לרוץ אז תהליכים שנמצאים בתור מתחת לא יכולים לרוץ עד שהתור העליון לא מתרוקן לגמרי. א. מהי הבעיה העיקרית במימוש זה וכיצד ניתן לפתור בעיה זו. ב. ידוע כי זמן הburst של שליש מהתהליכים במערכת הוא 12 יחידות זמן ושל היתר 40 יחידות זמן. מהו הtime quantum שהיית קובע ברמה הראשונה והשניה על מנת להביא לminimum average waiting time? ג. פתור מחדש את סעיף ב', אלא שהפעם הנח כי יש לך יכולת לשלוט גם על המעברים בין התורים (כלומר מאיזה תור יעברו לאיזה תור). צייר את התרשים ה MLFQ החדש והסבר.

MLFQ: יש כמה תורים, במקום תור אחד כמו שיש FCFS או בpriority schduling, אני מנהל כמה תורים, בשביל זה צריך לקבוע איזה process יכנס לאיזה תור, ובאיזה צורה ינוהל התור, גם צריך לקבוע איך נחלק את הזמן מעבד בין התורים (למשל לקבוע שכל מי שמעלי יש לו עדיפות, וכל זמן שיש מישהו בתורים שמעלי אז אני לא יכול להריץ תהליכים בתור שאני נמצא בו, לחילופין ניתן ליצר חלוקת זמן על המעבד בין התורים, למשל התור הנמוך יקבל 10% מזמן המעבד בכל רגע נתון, התור מעליו 30% וכך הלאה.) זה היה ההסבר על הmultilevel מה זה feedback, אומר שגם יש מעבר בין תורים, ז"א תהליך יכול למצוא את עצמו עובר לתור בעדיפות גבוהה יותר. א. הבעיה העיקרית היא starvation. התהליכים שנמצאים בתור ה FCFS עלולים למצוא את עצמם מחכים הרבה מאוד זמן כי כל הזמן יכנסו תהליכים לרמות שמעל. הפתרון- aging, אם יש לי תהליך שהוא בFCFS והוא מחכה כבר המון זמן אני יכול להחזיר אותו לתור משעליו, ואם הוא מחכה בתור שמעל כבר הרבה זמן אני יכול להחזיר אותו גם לתור הראשון. ב. השליש הזה הוא סתם מבלבל, ניתן להגיד ש"חלק מהתהלכים עם 12 יח' זמן וחלק 40". איך נביא לminimum average waiting time? למדנו שיבוץ שמביא למינימום הוא : shortest job first. עם preememption. (אם מגיע מישהו עם burst יותר קצר היינו רוצים שהוא ישובץ על גבי המעבד). נחשוב איזה זמנים נקבע לתורים שיביאו אותי כמה שיותר קרוב לSJF. תשובה: 12,28. איך עוזר לנו: אם היה לנו בתור הראשון 12, אז כל תהליך היה נכנס ואם הburst שלו הוא 12 הוא קיבל בעדיפות גבוהה את המעבד והוא מסיים, אם הוא בזמן של 40 אז הוא קיבל את ה12 , יורד למטה, אם יגיע תהליך חדש אז אומנם תהיה לו עדיפות כי הוא בתור הראשון (אבל את זה לא נוכל למנוע). מה יקרה לתהליכים ברמה השנייה? הם ירוצו ירוצו ירוצו, אם יסיימו את ה28 שלהם הם יצאו, אם יגיע תהליך חדש הוא יכנס לתור הראשון ויקבל עדיפות עליהם. (כמו שכבר ציינתי) למעשה כל תשובה של 12 ומספר מעל 28 תהיה טובה. מה היה קורה אם היינו בוחרים 12 ולמשל 20, אז אחרי התור השני היה יכול להשאר תהליך עם burst שנשאר לו עוד 8 (עשה 12 ואז עשה 20) עובר לFCFS ששם בכלל העדיפות היא הכי נמוכה ושם הוא יחכה הכי הרבה זמן, הוא עלול למצוא את עצמו במצב של starvation. (כלומר הburst שלו הכי נמוך והוא מחכה הכי הרבה זמן שזה מנוגד לגמרי לshortes job first). ג. כעת אומרים לנו שאנחנו כרגע לא רק יכולים לשלוט על הזמנים אלא גם על החצים, ז"א אפשר לא רק לרדת למטה אלא גם לעלות למעלה. עדיין אומנם שומרים על זה שהתור הראשון והשני הם RR והשלישי הוא FCFS. תשובה: תור ראשון 12, תור שני 16, ואז חץ למעלה- אל התור הראשון. בצורה זו אנחנו תמיד שומרים שהתהליך עם הזמן הקצר ביותר מקבל עדיפות. למה אנחנו מחזירים לתור הראשון? אם היה לו 40, אז אחרי 28 יח' היינו רוצים שהוא יחזור לתור העליון כדי לקבל מקסימום תעדוף ולא ירד לFCFS ועלול להתקע שם. ** כל העניין בתרגיל פה זה שיש עדיפות לפי תור ! ולא לפי הburst , וכדי שנגיע לminimum average waiting time אנחנו רוצים לתת עדיפות לפי הburst הקצר ביותר.

מה הקשר בין SJF ל Priority scheduling?

SJF זה סוג של priorty schduling, ככה שהprioirty נקבעת לפי אורך הburst. אגב גם FCFS זה סוג של priorty schduling שבו הPriorty נקבע לפי זמן ההגעה לתור, אבל בניגוד לpriorty schduling כללי, אין בFCFS הרעבה, מכיוון ש בFCFS אין מישהו שיבוא ויעקוף אותי בתור.

רשום שלושה יתרונות לשימוש בthreads:

-יעילות גבוהה יותר, יכול לייצר מקביליות בהרצה, מה שאני לא יכול לעשות לprocess שעובד על בסיס thread אחד. -data sharing, יותר קל, יש לנו חלקים בתוך הprocess שהthreads משתפים בינהם, הם כולם יכולים לגשת אליהם. -מבחינת מודלריות יותר נוח להשתמש בthreads כי אני יכול לפרק את המשימה המאוד מורכבת לחלקים יותר קטנים מה שהופך את הכל ליותר נוח - עלות ה context switch, ראינו מערכות ספציפיות שבהם עלות הcontext switch, לעשות context switch או אפילו לעשות thread חדש זה הרבה יותר זול (מבחינת זמן ומשאבים) מאשר לייצר process חדש או לעשות context switch בין שתי process.

מערכת MS-DOS אינה מספקת סביבה ל-concurrent processing. דון ב3 סיבוכים עיקריים שמוסיף הconcurrent processing למערכת ההפעלה.

concurrent processing= עיבוד מקבילי. ב MSDOS מריץ כל פעם תכונית אחת ולא עושה לה interrupts כי תומכים רק בתוכנית אחת בו זמנית. concurrent processing= מולטי פרוגרמינג. למעשה זה כמעט כל הדברים שלמדנו בקורס עד עכשיו. - מחייב מימוש time sharing על מנת שכמה תהליכים יוכלו לחלוק את המעבד. - מימוש הקונספט של preemption לתהליכים (שהרי לא יעזבו את המעבד בצורה יזומה בעצמם) - הרצה של קוד של הקנרל במקביל על ידי מספר תהליכים. -חייבים להגן על המשאבים של התהליכים מגישה לא מורשית של תהליכים אחרים. - חייבים להגביל את כמות המשאבים המוקצים לתהליכים. -חייבים לדאוג למנגנונים מתאימים לסינכורניזציה וטיפול בדדלוקים.

הנח כי ידוע לך כי בדיוק ביט אחד בfree block bit vector של מערכת ניהול הקבצים שגוי אולם אינך יודע באיזה ביט מדובר. תאר אלגוריתם למציאת הביט השגוי.

free block bit vector= על מ"ה לנהל את הבלוקים הפנויים, כדי להקצות אותם לקבצים שרוצים להגדיל, זה מתבצע באמצעות bit vecotr. כל ביט ממפה לאחד מהבלוקים בדיסק. הביט יקבל 0 אם הבלוק פנוי, ו-1 אם תפוס. מבנה זה של מערך מקל מאוד על מציאת רצף בלוקים פנויים (וכך להקצות בcontiguous allocation). אלגוריתם: *צור וקטור חדש שהגודל שלו כגודל הביט וקטור (כלומר כמספר הבלוקים שיש במערכת) *לך לdirectory, ותתחיל לעבור על הקבצים. -תעבור בין הבלוקים, ובכל בלוק כזה שאתה מטייל תרשום 1 או 0, ותסמן את הביטים. *תשווה בין 2 הווקטורים -תמצא את הטעות. אי אפשר לשפר את השיטה הזאת כי מבלי לעבור על הקבצים עצמם אין דרך למצוא איזה ביט הוא הביט השגוי.

יחידת ניהול זכרון MMU תומכת ב3-level paging ובעלת TLB. סמן את המספר המינמלי והמקסמילי של גישות לזכרון הנדרשת ע"י MMU זה כדי לתרגם כתובת לוגית לפיזית (יש לסמן שתי תשובות) א.0 ב.1 ג.2 ד.3 ה.4 ו.5

נזכיר מה זה 3 level paging: זה כאילו אני עושה היררכיה של הpage talbe כדי שלא יהיה מבנה רציף וארוך בזכרון לכן חילקנו להיררכיה בגודל 3. מדובר פה רק על הרגום לא מדובר על הגישה לכתובת שאני רוצה לגשת אליה, אך ורק על התרגום. (נזכיר שTLB הוא מרכיב חומרה של storage מהיר) 0 - זה המינימום, במצב בו הכתובת יושבת בTLBיש לנו כבר את הנתון לא צריך לגשת לזכרון או להיררכה של הטבלה (יש גם TLB וגם את הטבלה) 3- זה המקסימום, במצב בו הכתובת יושבת בטבלה הפנימית ביותר.

באיזו שיטת file allocation תשתמש עבור התקן הstorage של המערכות להלן. תשובות אפשריות: contiguous allocatoin, linked allocation, indexed allocation ו- ללא שימוש במערכת לניהול קבצים (raw). נמק בחירתך. א. בסיס נתונים בו משתנה תוכן הקבצים וגודלם באופן תדיר ויש צורך לקרוא ולכתוב במהירות נתונים לקבצים. ב. כונן חיצוני המשמש לאחסן סרטים. (הנח כי כל קובץ סרט הוא בגודל קבוע, וכי סרטים חדשים נכתבים מעת לעת ובהעידר מקום פנוי מבצע המשתמש מחיקה של סרטים קיימים). ג.קופסא שחורה במטוס, בה נשמר סרט נתונים קבוע (כגון מהירות, גובה) בכל שניה מרגע תחילת הטיסה ועד סיומה ולאחר מכן מועברים הנתונים לגביוי במחשב קרקעי. ד. כונן חיצוני לשמירת log files עבור תהליכים שרצים במערכת (הנח כי הכונן משרת מספר תהליכים, כאשר כל אחד כותב באופן תדיר לlog, וכי הקריאה מתוך הlogs מתבצעת לעיתים רחוקות כאשר מתרחשת תקלה או נדרש בירור)

נזכיר מה זה raw - ללא שימוש בfile system, זה לכתוב כל נתון במקום ספציפי בדיסק ואני לא נכנס באמת דרך האובייקט של הדיסק. א. indexed allocation. חשוב לנו מאוד הrandom access פה כי אנחנו רוצים מהר לקרוא ולכתוב (לכן זה מבטל את linked allocation). מצד שני אם נשתמש בcontiguous אז יהיה לנו פה external fragmantion כי כל הזמן הגודל של הקבצים משתנה. לכן נרצה indexed. ב. contiguous. משום שגודל הסרט הוא קבוע ולכן ולא תווצר external fragmantation. לא יהיה extrnal כי נוכל להשתמש בחור שנוצר בשביל סרט אחר (אם מחקתי סרט באורך של 90 דקות אני אמלא את זה בסרט אחר של 90 דקות) מבחינת ביצועים, השיטות האחרות יתנו אותם ביצועים אולם יהיה להם overhead ובסופו של דבר נשאר עם פחות מקום אחסון. ג.RAW. זו מערכת סגורה, אני יודע בדיוק מה אני כותב בכל רגע נתון, אני יכול לקבוע קונבנציה של מה יכתב איפה מראש, ולחסוך את כל הסיפור של הfile system. אני גם אחסוך מקום וגם אחסוך זמן כל פעם שאני ארצה לכתוב איזשהו קובץ. ד. Linked היא בחירת האידאילית כי הoverhead מינימלי במקרה הזה. אנחנו תמיד נוכל להקצות עוד בלוק ללוג שלנו, כיוון שהכתיבה היא לסוף ויש לנו מצביע לסוף אז אין לנו בעיה של למצוא את הבלוק הבא שרוצים לכתוב אליו. וכיוון שרק לעיתים רחוקות אנחנו רוצים לקרוא אז פחות אכפת לנו שיש לנו דרך לעבור כדי להגיע לבלוק, במידה ואני קורא את הלוג כולו אז הקריאה היא ברצף ואז זה קלאסי לlinked allocation.

מערכת paging משתמשת בכתובות של 16bit וגודל page של 4K. להלן הpage tables של שני תהליכים במערכת: (דקה 1:21:40) א.תרגם את הכתובת הלוגית 16,000 של process 1 לכתובת פיזית ב. כתובית לוגית 9000 של process 2 לכתובות פיזיות.

עשינו משהו זהה לגמרי, *הנוסחא לתרגום כתובת לוגית לכתובת פיזית היא: לבצע חלוקה בין הכתובת הלוגית לגודל הדף, נקבל שלם ושארית. את השלם נחפש בטבלה ונקח את המספר שמופיע, נסמן את המספר בnum. נעשה: שארית + num*גודל הדף = כתובת פיזית. לשארית נהוג לקרוא offset לשלם #page א. אצלנו: 16000 לחלק ל4096, נקבל שלם: #page: נקבל 3 שארית: offset: נקבל 3712 נלך לטבלה של תהליך אחד, נחפש את #3, הוא מצביע על 2. כלומר: 3712 +2*4096 =11,904 ב. אצלנו 9000 לחלק ל 4096, נקבל: שלם: #page: נקבל 2 שארית: offset: נקבל 808 נלך לטבלה של תהליך 2, נחפש #2, הוא מצביע על 7, כלומר: 808+ 7*4096= 29,480. *זה לא משנה שכתובות הן בגודל 16bit.

מה היתרונות העיקריים של layered approach לsystem design של מערכת הפעלה? חסרונות עיקריים ?

layered approach: גישה שאומרת אני אפתח את מערכת ההפעלה שלי בצורה שתחלק את כלל הפונקציונליות שיש לי במערכת ההפעלה לשכבות, וכל שכבה תבנה על בסיס השכבה שמתחתיה, ז"א אם אני רוצה לפעול לפי פונקציונליות מסוימות אני יוכל לקרוא רק לפונקציונליות שנמצאת רק בשכבה שמתחתיי, אני לא אוכל לקרוא לפונקציומליות שנמצאת בשכבה שמעלי. זה מייצר יחסית הרבה שכבות- נניח שהשכבה האפס היא החומרה ומעליה תהיה שכבה אחד שתפנה ישירות לחומרה, ומעליה שכבה שתיים שתפנה לדברים שקוראים לחומרה וככה עולה ועולה בשכבות עד שיש שכבה שהיא בעצם הממשק מול המשתמש. אז כשיש דבר כזה היתרון הגדול הוא שהdesign הוא מודלורי, קל יותר לדבג את זה ולתחזק, כי כל פעם שיש איזשהו באג אני יכול להתחיל משכבה 0 לדבג, לדבג מעליה את שכבה1, וכל שכבה שדיבגתי אני יכול לסמן וי ולהמשיך לבאה ולדעת שהבאג לא שם אלא הוא בהכרח בשכבות מעל. כלומר מתודלוגית מאוד קל לתחזק מערכת כזאת ולמצוא ולתקן באגים שמתגלים בה. בניגוד לdesgin רגיל שבו כל שינוי יכול שנעשה יכול לבוא ולהשפיע על הרבה מאוד מרכיבים של המערכת ולא בהכרח נדע איך לגשת לסיפור הזה- תהליך הדיבאגינים יהיה הרבה יותר קשה. תשובה רישמית: הdesign מודולרי ולכן קל יותר לדבג, ולתחזק , ולשנות את המערכת מכיוון שכל שינוי משפיע רק על מקטע מאוד ספציפי של המערכת (בניגוד לdesign רגיל שבו כל שינוי יכול להשפיע על מרכיבים רבים של המערכת). חסרונות עיקריים של layered approach: - הביצועים, כל בקשה, למשל להגיע לחומרה, צריכה לעבור הרבה שכבות בדרך, בגלל החלוקה הזאת של פונקציונליות. - קשה לתכנן דבר כזה, לא תמיד אני אדע לפרק בצורה נקייה את הפונקציונליות שלי לשכבות.

מה ההבדל בין system call ו system program? תן דוגמא אחת לכל אחת מהשתיים

system call זה קריאה לפונקציונליות של מ.ה שאסור לנו לעשות בעצמנו, מ.ה עושה את זה בשבילנו מהמון שיקולים. system program- תוכנית שהגיעה יחד עם מ.ה, היא לא חלק מהקרנל, היא פשוט עוזרת לנו כמשתמשים לעשות פונקציונליות מסוימת, היא בעצמה קוראת לsystem call. דוגמאות לsystem calls: open(), close(). דוגמא לsystem program, צייר, סוליטר.

להלן 2 תהליכים הרצים במקביל: 1:30:00בסרטון process 1: for (i=0;i<5;i++){ y=y+2 { process 2: for (j=0;j<10;j++){ y=y+3 { הנח כי במערכת מעבד יחיד, וכי משתנה y משתנה משותף לשני התהליכים והוא מאותחל ל0. במידה ושני התהליכים סיימו את פעולתם: א.מהו הערך הגבוה ביותר האפשר של y? נמק והסבר. ב. האם Y יכול לקבל ערך של 3 לאחר ששני התהליכים סיימו את פעולתם? במידה ולא, מה הערך המינימלי שיכול לקבל? נמק והסבר. ג. אם הפעולה y=y+2 בתהליך 1 הייתה פעולה אטומית, מהם הערכים הסופיים שהיה יכול לקבל y? נמק והסבר.

א'. 40. התוספת המקסימלית לY באמצעות תהליך 1 היא 10 ובאמצעות תהליך 2 היא 30. ב'. לא יכול לקבל 3. בשביל ש Y יהיה 3 צריך שתהליך 2 יקדם אותו פעם אחת, וכל יתר הניסיונות של תהליך 2 ידרסו וגם כל הניסניות של תהליך 1 ידרסו. ובכל זאת מה הערך המינימלי שאפשרי? 5. איך נגיע ל-5 ? מה שעושים בפועל זה השמה ברגיסטר של הערך של Y והגדלה של הרגיסטר ב2 /3 והחזרה לזיכרון. המחזה לאיך בדיוק נגיע ל5: תהליך 1 מקבל את המעבד ומתחיל, הוא צריך לבצע y=y+2, לוקח את הערך של y שכרגע 0 ומכניס אותו לרגיסטר, הוא מגדיל את הרגיסטר ב2, אבל אחרי שהוא הגדיל ב2 יש context switch, ועכשיו תהליך 2 מקבל את המעבד.(לא עשינו השמה לזכירון זה נקטע באמצע, זה עדיין ברגיסטר) תהליך 2 מריץ את הלולאה 9 פעמים, מגדיל ב3 ומחזיר, כעת y=27. עד כה תהליך 2 רץ 9 פעמים ותהליך 1 עדיין באמצע ההרצה הראשונה שלו, הערך ברגיסטר שלו הוא 2. עכשיו אחרי שתהליך 2 רץ 9 פעמים יש context switch,חזרתי לתהליך 1, כעת תהליך 1 צריך להזין את המידע מהרגיסטר למשתנה y, אז הוא בעצם דורס את הערך שיש כבר בy ושם שם 2. עכשיו מעבירים את המעבד לתהליך 2, נשאר לו איטרציה אחת לעשות, הוא מגדיל את הרגיסטר ל3, נקבל ברגיסטר ערך של 5,אבל לפני שהוא כותב למשתנה y , עושים context switch וחוזרים לתהליך 1, עושים את הלולאה עוד 4 פעמים. כעת הy יהיה 13. תהליך 1 מסיים, חוזרים לתהליך 2, נשאר רק הפעולה של השמה של הרגיסטר במשתנה, הרגיסטר היה 5 ולכן נשים במשתנה y , את הערך 5 ונסיים את הריצה כולה. *חשוב לזכור שכל הפעולות שעושים עוברות דרך רגיסטר. ג. מה זה אומר פעולה אטומית? זה אומר שאת כל העברה לגיסטר וההחזרה הכל נעשה בלי שאני יכול לעשות Interrupt באמצע. זה אומר שכל הפעולה y=y+2 מתבצעת במכה אחת בלי שאפשר לעצור אותה באמצע. מה בעצם "דופק" אותי עכשיו? בסעיף ב' הייתה לנו דריסה הדדית, תהליך 1 דרס 9 איטרציות של תהליך 2, והתליך 2 דרס 4 איטרציות של תהליך 1. כעת מרגע ש1 עושה משהו הוא עושה אותו עד הסוף. רק תהליך 2 יכול לדרוס את תהליך 1. במקרה הכי גרוע תהליך 2 דרס את כל האיטרציות של תהליך 1, הסנריו: תהליך 2 העביר לרגיסטר ואז תהליך 1 פעל 5 פעמים, ואז תהליך 2 העביר מהרגיסטר למשתנה וכל מה שתהליך 1 עשה נדרס. כלומר: נקבל ערכים בין 30 ל 40. במקרה הכי גרוע יכולים להפגע 5 איטרציות של תהליך 1 במקרה הטוב הם לא יפגעו כלל.

במהלך הקורס עסקנו רבות בשיטת התזמון SJF. מה צריך להתקיים על מנת ש SJF יביא למינימום את ה average waiting time?

אמרנו שתחת תנאים מסויימים ה SJF יביא למינימום את הaverage waiting time. מהן התנאים הללו ? - preemptive (זכות קדימה למי שיש לו burst נמוך יותר) -context switch זניחים, אם אני אעשה SJF שהוא preemptive וכל הזמן יהיו לי החלפות ותהליך עשוי למצוא את עצמו נכנס למעבד ויוצא המון, כל פעם כזאת זה context switch ואם הוא לא זניח אז יוצא שכרי בהפסדי ולא נביא למינימום average waiting time. אם הcontext switch עולה לי הרבה אולי בכלל עדיף לעשות ב FCFS ואז אין כמעט context switch בכלל כמעט החלפות.

הquantum הוא: א. פרק הזמן המינימלי העומד לרשות התהליך לריצה על גבי המעבד. ב. פרק הזמן המקסימלי שהתהליך יכול לרוץ בטרם יעשו לו preemption. ג. פרק הזמן שהתהליך רץ בטרם יצא לI/O ד. פרק הזמן ההממוצע העומד לרשות התהליך לריצה על גבי המעבד

ב'.

הסביר העיקרית לשימוש ב DMA היא: א. לאפשר למעבד לרוץ בקצב מהיר יותר. ב. שיפור ביצועי המערכת על ידי הגדלת המקביליות ג. לאפשר למעבד להגיב מהר יותר להתקני הקלט/ פלט. ד.מיקסום הניצול על שטח הדיסק ה. אף תשובה לא נכונה.

ב'. בזמן שאני משתמש בDMA המעבד יכול לעשות דברים אחרים, כי אני מעביר ישירות לזיכרון במקום שהמעבד יעשה את זה. התשובה הזאת של לאפשר למעבד לרוץ בקצב מהיר יותר, חוזרת המון אבל היא כל פעם שגויה, אי אפשר לגרום למעבד לרוץ בקצב מהיר יותר, יש לו קצב ריצה, אי אפשר שפתאום הcyclecs שלו יהיו יותר מהירים.

בניגוד למערכות soft real-time computing, במערכות hard real-time: א. קשה לחזור מתי יסיים תהליך את ריצתו ב. ידוע בדיוק מתי כל תהליך צפוי לרוץ ג.אין טעם להריץ את התהליך אם לא נעמוד בdeadline שמוגדר לשיבוץ על המעבד. ד. קשה לחזור מתי יסיים תהליך את הburst הנוכחי שלו.

ג. זה נושא של schduling אמרנו שמערכות hard real time אין טעם להריץ את התהליך אם לא נעמוד בdeadline שמוגדר לשיבוץ על המעבד, ואז מה שהתהליך יבקש זה שיעשו לו reserve, הschduler שומר לו חלון זמן להרצה ועומד במילה שלו. אם הוא לא יכול לעשות את זה אז הוא מודיע לתהליך שאין לו שיבוץ בכלל. בsoft real time computing אנחנו עושים את זה דרך הpriority אנחנו בתהליכים שמאוד חשובים לנו ניתן להם priority מאוד גבוה וזה יגרום לזה שהם יקבלו את המעבד בזמן שהם צריכים אבל שוב אנחנו לא יכולים להבטיח.

מה ההבדל העיקרי בין process ל program

ה- process הוא למעשה תוכנית בהרצה (ישות פאסיבית לעומת ישות אקטיבית). התוכנית היא רק הקוד והנתונים ואילו ה- process משנה את ה- state שלו במהלך הריצה.

הקוד השלישי ב3:29:30

ההבדל כעת הוא בgate , שהוא כעת מאפשר להכניס 15 פילוסופים. א. גם כאן זה פותר את בעיית הדדלוק, במקסימום יש 15 שיכולים להתחרות על המקלות וכעת בוודאות יהיה פילוסוף שיוכל לאכול (כי מישהו מהם יצליח לקחת 2 מקלות). ב. יכולה להיות הרעבה, באותו אופן של הסעיפים הקודמים. ג.במקרה הגרוע פילוסוף אחד בלבד יוכל לאכול, משום שיתכן ש14 מחזיקים מקל אחד וכולם מחכים לו שיסיים ד. גם כאן לא תהיה הרעבה במימוש של מחסנית

הוספת שאלות מהמצגת "Hazara till ch7"

הוספת שאלות מהמצגת "Hazara till ch7"

הוספת שאלות ממצגת "חזרה"

הוספת שאלות ממצגת "חזרה"

מה הן הבעיות העיקריות השימוש ב working set?

העבר לא בהכרח חוזה את העתיד והworking set משנה את גודלו ותוכנו, ז"א הworking set שלנו כל הזמן מודד אחורה, הוא לא מודד את מה שקורה עכשיו, בשביל לדעת מה שקורה עכשיו היינו צריכים גם את ההסתכלות קדימה ולא רק אחורה. מדידה אמיתית של הworking set היא בלתי מעשית וניתנת לקירוב בלבד. דורש למעשה לtimestamp לכל קריאה מהזכרון ותחזוקת queue בו יסודרו הpages של כל תהליך לפי סדר הקריאה שלהם, ואז נרצה למדוד כמה pages ייחודים כאלה יש לנו. זה הרבה מאוד משאבים שצריך להפעיל על כל נגיעה בזכרון.

יש בסיכום של שניר ובסוף הרצאה 11 שאלה על מספר פעולות שצריך לבצע, לא כתבתי עליה אבל היא אחלה אז תעבור עליה בבו העת

יש בסיכום של שניר ובסוף הרצאה 11 שאלה על מספר פעולות שצריך לבצע, לא כתבתי עליה אבל היא אחלה אז תעבור עליה בבו העת

הקוד השני ב3:24:34

כעת יש שער שמאפשר רק לחצי מהפילוסופים לעבור אותו ולהתחרות על הsemaphore. א.לא יכול להיווצר דדלוקף משום שהgate שומר על כך שבמקסימום חצי מהפילוסופים ינסו להשיג שני מקלות. כל האחרים או שלא מנסים או שמחזיקים כבר שני מקלות (כלומר ישחררו אותם מתישהו) כלומר תמיד מישהו יוכל להתקדם כשמישהו יסיים. ב. כן, מאותה סיבה כמו מקודם ג. במקרה הגרוע ביותר יהיו לנו 4 פילוסופים שאוכלים (מחזיקים שני מקלות ביד) ו8 שמחזיקים מקל אחד ומחכים לשני. ד. במידה וממומשת מחסנית לא תהיה הרעבה, כל יתר התשובות לא משתנות

האם ניתן לזהות מצב של thrashing באמצעות ניתור רציף של כמות הpage faults שקרו במהלך X הפקודות האחרונות. במידה וכן, רשום כיצד, במידה ולא- ציין איזה עוד מדד/ים נדרשים לצורך הזיהוי.

לא, יכול להיות שתהליך רק מתחיל לרוץ ואז בהתחלה יהיו מלא Page faults עד שכל הלוקאליטי שלו יהיה בזכרון. או לחילופין יכול להיות שעברנו מלוקאליטי אחד לאחר, ואז יהיו הרבה page faults כתוצאה מכך אבל זה לא אומר שאנחנו במצב של thrashing. אז איזה עוד מדד נצטרך? אחוז הניצולת של המעבד. אמרנו שאם אחוז הניצולת של המעבד היא נמוכה אז גם יש הרבה page faults אבל אנחנו נמצאים גם במצב של thrashing. אבל אם הניצולת של המעבד היא גבוהה זה אומר שאנחנו לא סובלים פה מהעניין של page faults ואין thrashing.

האם ייתכן שprocess שהיה במצב של waiting יעבור למצב של terminate? הסבר.

לא. על מנת שprocess יסתיים הוא צריך להריץ את הפקודה exit. exit היא כמובן system call, ולכן ידרש זמן מעבד, ולכן לא יכול לעבור מwaiting ל terminate. הוא צריך לעבור קודם דרך מצב ready מה שיחזיר אותו לready queue, ואחרי שהוא יהיה בready queue הוא יצטרך להבחר ע"י הscheduler, אחרי שהוא נבחר ע"י הscheduler הוא יוכל להריץ את הsystem call exit ולסיים את דרכו. כלומר צריך להיות running בשביל לבצע terminate, ובשביל להיות running צריך כמובן לרוץ ע"י המעבד, כדי לרוץ ע"י המעבד צריך להיות בready queue ולהבחר ע"י הschduler.

נתונה מערכת מחשב עם מעבד יחיד. 1GB זכרון ודיסק בגודל 300GB. מערכת ההפעלה של המחשב עובדת עם demand paging. עם מדיניות החלפה לוקאלית ותזמון CPU על בסיס Multi level feedback queue (MLFQ), עם שתי רמות. בראשונה מבוצע הזתמון לפי RR ובשני לפי FCFS כאשר לרמה הראשונה תמיד יש עדיפות על פני השנייה (כלומר preemptive. במערכת רצים שני תהליכים שהם במהותם CPU bounded. תהליך א' ותהליך ב'. לתהליך א' יש working set בגודל 50GB ולתהליך ב' יש working set בגודל 100mB. הנח כי הקצאות הזכרון הראשונית לתהליכים היא מסוג equal allocation. וכי המערכת פעלה רק זמן מספיק והגיעה למצב היציה שלה כאשר שני התהליכים רצים. א. איזה מהתהליכים (כאשר הם במצב ready) יקבל לדעתך עדיפות גבוהה יותר בשיבוץ על ה CPU? נמק. ב. כיצד היתה משתנה תשבותך לו היו מוספים מעבד נוסף זהה למערכת? נמק. ג. כיצד היתה משתנה תשבותך לו במקום להשתמש במדיניות החלפה לוקאלית היה מתבצע שימוש במדיניות החלפה גלובאלית? נמק.

מה זה אומר מדיניות החלפה לוקאלית? שכך תהליך אם יש לו page fault אם יש לו victim יבחר מבין הpages של עצמו שנמתאים בזכרון. תהליכים שבמהותם הםCPU bounded משמע הם צריכים את המעבד וכמעט ולא יוצאים לIO. היה לנו 1 GB וחילקנו אותו שווה ושווה, כלומר כל תהליך קיבל 500 MB. התהליך הראשון צריך 50GB שזה הרבה הרבה יותר מ 500MB וכנראה שהוא יהיה במצב של thrashing, משמע הוא יצא הרבה מאוד לIO. (הואלא יצליח להכניס את הלוקאליטי שלו ב0.5GB שהוא קיבל) התהליך השני גם הוא קיבל 0.5GB אבל הworking set שלו הוא רק 100MB ולכן אין לו בעיה להכיל את כל הworking set שלו במסגרת הזכרון שיש לו. נשים לב להיררכיה של הschudling שלנו, הרמה הראשונה היא RR הרמה השנייה היא FCFS. התהליך השני שכל הworking set שלו נמצא בזכרון הוא נכנס לרמה הראשונה ואז אחרי שהוא מסיים את הזמן שנתנו לו בRR הוא יורד לרמה השנייה, בניגוד אליו התהליך הראשון התחיל לרוץ על גבי המעבד ברמה הראשונה ומהר מאוד יצא לIO. כשהוא יחזור מהIO הוא חוזר כמובן לתור של הרמה הראשונה, ז"א רוב זמנו הוא יבלה ברמה הראושנה (של הRR). א. אז אם שניהם במצב ready סביר להניח שנמצא את התהליך הראשון ברמה הראשונה והשני ברמה השנייה, אז למי במצב כזה תהיה עדיפות על המעבד- > לכבד יותר, לזה שברמה הראשונה. (על אף שזה פחות אינטואיטיבי לנו) אז אם שניהם נמצאים כרגע במצב ready, סביר להניח שהכבד יותר הוא זה שנמצא ברמה הראשונה ולכן הוא זה שיהיה בעדיפות על גבי המעבד. *תמצות לזה במילים שלי: מה שקורה פה בעצם זה שיש שני תהליכים, בגלל שהשני נורא מהיר הוא יסיים בקלות את הרמה הראשונה וירד לשנייה, מה שיגורם לראשון לקבל עדיפות אצל המעבד כי הוא יתקע שם ברמה הראשונה (נזכור שרק אחרי שכל התהליכים מסיימים את הרמה הראששונה אפשר להתחיל לעבוד על הרמה השנייה) ב.היא לא הייתה משתנה. מהסיבה הפשוטה שאומנם היה לנו מעבד לתת לשניהם, אבל עדיין התהליך הכבד יותר היה נמצא ברמה הראשונה רוב הזמן, ולכן השאלה היא למי יש עדיפות-> עדיין לזה שברמה הראשונה, והתשובה לא תשתנה. ג. זה היה משתנה. התהליך הזה שכל הזמן יש לו Page faults לאט לאט היה לוקח frame של התהליך השני שאין לו page faults (הוא כאילו היה עוזר לו, זה מדיניות גלובאלית) ואז זה שהיו לוקחים ממנו באיזשהי נקודה גם לו יהיו page faults ואז גם הוא חוזר לרמה הראשונה, יותר ויותר, עד שכמות הpage faults של שניהם היא פחות או יותר שווה. אז הם כבר לא לוקחים אחד מהשני אלא מחליפים בתוך עצמם, ובמצב זה סביר להניח שנמצא את שניהם ברמה הראשונה. ותהיה להם את אותה עדיפות על גבי המעבד.

(שאלה מהמבחן של שנה שעברה מועד א') מערכת ההפעלה myBIOUS היא מערכת הפעלה מודרנית התומכת בmultiprogramming. בניסיון להתאים את המערכת למערכות מחשב קטנות וזולות בעלות מעבד יחיד הוטל עליך לשנות התוכנה כך שלא תתמוך יותר בmultiprogramming (ובכלל זה multi- thrading). סווג כל אחד מהמולים הבאים בהתאם לשינוי שיצטרך לעבור: שינוי מהותי, שינוי קטן אם בכלל, או שניתן לבטלו כליל. את המודולים הבאים אכתוב כבר בתשובה.

מה שחשוב להבין זה שיש מעבד יחיד, ושאנחנו לא הולכים לתמוך יותר בmulti threading. זה אומר שבכל רגע נתון אנחנו הולכים לתמוך רק בתהליך אחד, בדיוק כמו במערכת הפעלה dos (מגבלות הms dos).אנחנו למעשה עושים שנמוך למערכת לא שדרוג. - גישה לחומרה: שינוי קטן/ אפשר גם מהותי. אנחנו הולכים לעבור ממערכת שתמכה לנו ב- multi threading ואנחנו הולכים להפוך אותה למערכת שמטפלת רק בתהליך אחד, כלומר אנחנו עוברים ממערכת שידעה לשמור ממצבים שכמה תהליכים ניגשים לחומרה/ מכאלה שניגשים לחומרה כאשר היא לא מוקצת להם, כלומר היה פה המון קוד שקשור לניהול הגישה לחומרה כשהיה כמה תהליכים שרצו במקביל על המערכת. לכן נצטרך להוריד את הקוד הזה, השינוי יהיה יחסית קטן. (היה נוטה לקבל גם שינוי מהותי) - Long term Scheduler: ניתן לבטל. מה שעושה הLong term Scheduler זה קובע מי ישב בזכרון, וכיוון שאין לי כמה תהליכים שרצים במקביל אז לא צריך אותו יותר, כי התהליך שאני מריץ כרגע הוא התהליך שיהיה בזכרון ואין לנו בו טעם. הוא מסווג איזה תהליכים ישבו בready queue, אבל בגלל שיש רק הרצה אחת, אין צורך בזה בכלל. - Short term Scheduler: ניתן לבטל. אין פה התלבטות, מי שירוץ על הזכרון הוא התהליך יחיד, אין במקביל. הרי הshort term הוא המחליט איזה תהליכים ירוצו מתוך התהליכים שבready queue, אבל יש רק אחד. - טיפול בשגיאות: שינוי קטן אם בכלל. שגיאות עדיין יקרו, (למשל חלוקה ב-0/ גישה לקובץ שלא שלי) זה עדיין משהו שצריך התייחסות אליו. -טיפול בinterrupts: שינוי קטן אם בכלל. כי עדיין צריך את הinterrupts האלה, כלומר אם עובדים בצורה אסינכורנית ברגע שה-device סיים את הפעולה שלו הוא צריך לסמן לי שהוא סיים. -ניהול זכרון: שינוי מהותי. כעת אין לנו מה לנהל, כעת אנחנו נותנים את כל הזכרון לתהליך שלנו שאנחנו מריצים, ואנחנו לא באמת צריכים לנהל פה משהו, כיוון שיש רק אחד נשאף לשים אותו בcontigous allocation ולתת את הזכרון כולו לאותו תהליך שאני מריץ. -טיפול בדדלוק: ניתן לבטל. כי בהגדרה מחייב אותנו ל2 או יותר תהליכים -תמיכה בסינרונזציה: ניתן לבטל. מאותה סיבה -CLI: שינוי קטן אם בכלל. עדיין צריך לספק למשתמש איזשהו command line interprter (אותו מרכיב במ"ה שיודע לקבל מהמשתמש פקודות ולהפוך אותם לsystem calls) במוד שבו אנחנו מטפלים רק בתוכנית אחת, עדיין צריך לספק למשתמש את אותה גישה לפונקציונליות של מ"ה בשביל שהוא יוכל להריץ את התוכנית שהוא רוצה להריץ שיוכל לעצור אותה שיוכל לקבל כל מיני מידע מהמערכת. מבחינה פונקציולית יהיה פחות פונקציונליות שמה כי אני לא מאפשר להריץ תהליך אחר בזמן שהתליך אחד רץ, ולכן מדובר פה בשינוי קטן. -Message Passing: ניתן לבטל. למי אני יעביר את ההודעה אם אני היחידי בעולם? - Accounting (מנהלים רישום/ סטטיסטיקה, של כל מה שקורה במערכת, מי נכנס, מי השתמש, באיזה קובץ השתמש, כמה זמן השתמש.. משמש בעיקר כמה כל תהליך צריך לשלם על המערכת לפי השימוש שלו)- לכן שינוי קטן. כי נצטרך לרשום רק על תוכנית אחת בו זמנית ולא על כמה. -Protection and Security: שינוי מהותי. כמעט כל מה שיש שם עכשיו לא צריך אותו, כל מה שישאר זה רק עניין הקבצים אם בכלל. כל השאר- נגיעה בזכרון שלא שלי, ניסיון לגשת למשאבים שכרגע לא מוקצים לי וכו' לא נצטרך אותם. (כל המשאבים הם שלי, לכן אין העניין הזה של גישה למשאבים שלא שלי, אני בן יחיד, הכל בשבילי)

מה הוא מצב של priority inversion? הסבר והדגם. כיצד ניתן לפתור בעיה זו?

מצב של priority inversion: מדובר במצב שבו תהליך בעדיפות גבוה לא יכול לרוץ כי ממתין למשאב שמחזיק תהליך בעדיפות נמוכה, שגם הוא לא יכול לרוץ כי יש מישהו עם עדיפות גבוהה ממנו (אבל עדיין נמוכה מזו של הראשון) שרץ. הפתרון- העברה זמנית של העדיפות של הראשון לשני על מנת שיוכל לרוץ ולשחרר את הראשון. למשל כמו שהסברנו בהרצאה, יש 3 תהליכים עם עדיפות של: נמוך, בינוני, גבוה. אם הנמוך התחיל (כשהוא היה לבד בready queue) תפס משאב, ואז הגיעו התהליכים הבינוני והגבוה, אז התהליך עם הpriority הגבוה לא יכול לרוץ כי המשאב שהוא צריך תפוס, אבל למרות שהיינו רוצים שהתהליך עם הpriority הנמוך יתקדם וישחרר רגע את המשאב אבל אנחנו בעצם מריצים את התהליך עם הpriority הבינוני. וזה לא משהו שהיינו רוצים שיקרה. מה שעושים זה מעבירים זמנית את הpriority של התהליך הגבוה לתהליך הנמוך. בצורה זו התהליך עם הpriority הנמוך יכול להתגבר על התהליך עם הpriority האמצעי, לשחרר את המשאב, יחזיר את הpriority לתהליך הגבוה והתהליך הגבוה יקבל את המעבד ויוכל להמשיך לרוץ. *שאלה שנשאלת פה בכיתה: אם לא היינו משתמשים בpriority inversion , היה אפשר להחשיב את זה לdeadlock? לא, כי התהליך האמצעי היה מסיים. זה כן אולי היה starvation. כי כל הזמן היו מגיעים תהליכים שעוקפים את התהליך עם הpriority הנמוך. כי בסופו של דבר התהליך האמצעי אמור לסיים ואז התהליך הנמוך יוכל לרוץ לסיים ולאפשר לתהליך הגבוה את המשאב.

קיבלת את הsource code של מערכת ניהול קבצים כלשהו (file system) ונתקשת לדווח האם מדובר במערכת העושה שימוש בcontiguous allocation או בindexed allocation. מה תחפש בקוד על מנת לענות על השאלה?

נבדוק האם יש לנו מערך שלתוכו נקרא את הindexed block או לחילפוין מה שמעניין אותי זה בלוק התחלה וגודל הבלוק. רישמי יותר: יש לחפש את מבני הנתונים שמשמשים כמצביעים לבלוקים של הקובץ. במקרה של indexed allocation נצפה למצוא מערך של מצביעים וייתכן אף מצביעים למערכים נוספים. בנמקרה של contiguous allocatoin נצפה למצוא מצביע לבלוק התחלה ומספר המציין את כמות הבלוקים העוקבים בהם עושה הקובץ שימוש.

יש פה שאלה דיי פשוטה של חישובים לגבי RR, SJF-non preemptive, FCFS, Priority. סביבות 1:21:00 תעיף מבט במידה ותתקע

נוסחא לחישוב average waiting time: סיים פחות הגיע פחות burst.

במהלך ריצה תהליך משתנה הworking set שלו הן מבחינת גדולו והן מבחינת תוכנו. סמן בתרשים להלן את החלקים בהם הworking set יציב ואפקטיבי, ואת החלקים בהם מצוי הworking set בתהליך שינוי. (דקה 1:08:28)

תזכורת- הworking set מנסה למדוד את גודל הלוקאליטי. בגרף ניתן לראות עקומה שמראה את הsize של הworking set כהתקדמות התהליך. הוא יציב כאשר העקומה לא עולה, והוא בתהליך של שינוי כאשר העקומה עולה/ יורדת, כי זה אומר שזה מעבר בין לוקאליטי אחת לשנייה. זה גדל כי הworking set מנסה למדוד את הלוקאליטי. בשלב המעבר הוא תופס חלקים מהלוקאליטי הישנה וחלקים מהחדשה, בגלל זה יש גידול מעבר למצב היציב. ברגע שהוא מסיים לתפוס את הworking set של הלוקאליטי החדש, לאט לאט מתחילים להפלט מרכיבים שהworking set הכללי מהלקואליטי הקודם ואז מתחילה התייצבות.

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

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

צפייה בסרטון הכנה למבחן של 2019 ביוטיוב, דודי פותר שאלות ממבחני עבר על כל הנושאים שהיו לנו חוץ מניהול זכרון

צפייה בסרטון הכנה למבחן של 2019 ביוטיוב, דודי פותר שאלות ממבחני עבר על כל הנושאים שהיו לנו חוץ מניהול זכרון

הוכח כי אכן ה SJF מביא למינמום average waiting time (תחת התנאיים שציינת בשאלה הקודמת)

ראינו את ההוכחה בכיתה, יהיו שני תהליכים a,b. כך שהburst של a יותר ארוך משל b. ו a משובץ לפני b. החלפה שלהם תביא חיסכון לקצר שהוא גדול יותר מהנזק לארוך

שאלה אמריקאית: במערכת בעלת זכרון וירטואלי, בעת שחסר לתהליך דף בזכרון, מבוצע: א. תמיד swap in ב. תמיד swap out ג. תמיד TLB hit ד. תמיד swap out וגם swap in

תשובה א' לא משנה מה קרה, עצם זה שהיה חסר דף בזכרון זה אומר שצריך להכניס אותו לזכרון ולכן נעשה swap in. למה לא יהיה תמיד גם swap out? יכול להיות שבזכרון יש מקום פנוי ולא צריך לעשות swap out. למה שלא תמיד יהיה TLB hit ? לא בהכרח בכלל נשתמש בTLB, וגם אם כן נשתמש זה לא בהכרח אומר שיהיה לנו TLB hit. הTLB מותן לנו איזשהו subset מתוך הpage table , אם היה חסר דף בזכרון זה אומר שבהכרח לא יכול להיות שהוא נמצא לי בTLB, אז לא היה TLB hit .

באלו מהמקרים הבאים מתרחש תהליך של preemption? א. כאשר הquantum המוקצה לתהליך מסתיים. ב. כאשר תהליך מבקש לבצע I/O. ג. כאשר נכנס תהליך חדש לready queue בתזמון FIFO ד. כאשר התהליך מבקש לסיים exit.

תשובה א' למה זה לא ב'? כי כאשר תהליך מבקש לצאת לI/O הוא עובר למצב של waiting, לא צריך לעשות לו preemption, הוא בעצמו מבקש לצאת. התהליך של הpreemption זה כשתהליך רוצה להמשיך לרוץ ואני לוקח לו את המשאב. זה לא שהוא בעצמו מבקש לעזוב את המשאב. ג. FIFO זה לפי סדר הכניסה אז בוודאי שלא צריך לעצור את התהליך. ד.כאשר תהליך מבקש לסיים זה כמובן לא באמת preemption כי זה הוא מבקש לסיים ומחזיר את המשאב.

מה לא תצפו למצוא בשיטה של segmentation with paging? נקראת גם MULTICS. א. External Fragmantation ב. TLB ג.Internal Fragmatation ד. Page Table

תשובה א'. כל הרעיון של השיטה הזו הוא שנממש את הסגמנטים באמצעות pages כלומר בגדלים קבועים, ולכן אני יכול לעבוד עם frames בזכרון ולמנוע extrnal fragmantation. אני כן אצפה למצוא TLB וpage Table כי ככה עובדים עם השיטה מה שהשיטה באה לפתור זה את הפרגמנטציה החיצונית, בכך שהיא מחלקת לpage בגודל קבוע היא מאפשרת לא לשמור את המידע באופן רציף בזכרון וככה לסתום חורים. כן הגיוני לראות Internal Fragmantation כמו שראינו בסעיף הקודם במצב שבו חילקנו לדפים בגודל 2048 אבל הגודל של המידע היה קטן מזה בהרבה אז נוצרו חורים פנימיים.

מה היתרון בשימוש בContigoius Memory Allocation א. יש Random access ב. אין External Fragmenation ג. יש Internal Framentation ד. יש thrashing.

תשובה: א' ראשית נעיף את סעיפים ג' וד' שהם בכלל לא יתרונות, הם חסרונות. ב'- יש Extranal Fragmantiation. Random access זה יתרון ענקי של ההקצאה הזאת. thrashing- זה מצב שיש לי מעט מדי זכרון פיזי שמוקצה לתהליך (מעט מדי frame שמוקצים לתהליך) עד כדי שאני לא יכול להחזיק את הלוקליטי של התהליך ואז כל הזמן יש לי page fault ואני מבלה את כל זמני בלהוציא ולהכניס מהזכרון, זה דבר מאוד מאוד רע, זה מביא את הנצילות של המערכת לאפס. *יש לשים לב היטב לא לערבב שיטות לניהול זכרון עם שיטות לניהול קבצים !! בניהול זכרון יש לנו (2וחצי שיטות): - Contigoius Memory Allocation - paging - סגמנטים (חצי שיטה)

שאלה שמתחילה ב1:24:15. דודי אומר שהיא מאוד חשובה למבחן. דני רוצה לעצב מחדש את הpage table. הרעיון הוא להעתיק את מנגנון ההצבעה לבלוקים של קובץ בדיסק כפי שממומש בunix. זאת מכיוון שברוב התוכניות עיקר הdata מצוי בתחילת הaddress space. על פי המימוש המוצע, ימומש הpage table כ two level page table בתוספת שינוי להלן: המחצית הראשונה של הטבלה הראשית (Outer page table) תוקדש למיפוי ישיר של pages ל frames בזיכרון והמחצית השניה של הטבלה הראשית תצביע לטבלאות משנה כפי שמבוצע במימוש הסטנדרטי של two level page table. נסמן את הרשומות במחצית הראשונה של הטבלה הראשית כfast ואת הרשומות במחצית השניה כnormal. ענה על השאלות הבאות בהנחה שייצוג כתובות במערכת הוא באמצעות 32bits , גודל הpage הוא 4KB והן הטבלה הראשית וכל אחד מטבלאות המשנה תופסים בדיוק page אחד. א. כמה pages במערכת של דני הם fast pages? (יש לתת מספר מדויק) ב. כמה pages הם normal pages? (יש לתת מספר מדויק) ג. מהו גודל מרחב הכתובות הוירטואלי המקסימלי בבתים (ניתן לרשום את התשובה כחזקה). ד. בהנתן שגם קיים TLB במערכת והhit ratio הוא a=0.9, בכמה אחוזים השתפר הeffective access time באמצעות השיטה החדשה ביחס למצב בו ממומש הpage table כ two level page table סטנדרטי (הנח שזמן הגישה לTLB זניח)

(הרצאה 11 למידע) יש פהtwo level page table כלומר הטבלה החיצונית, והיא מצביעה על טבלה רלוונטית וממנה אני מגיע לframe המתאים. ניתן לראות ב1:28:27 המחזה לאיך ניראה הpage table הנוכחי, החצי הראשון מצביע באופן ישיר על frames בזכרון. החצי השני יצביע לטבלאות שמהם יהיה מצביעים לframes שבזכרון. בהתאם לזה זה נקרא fast pages ו normal pages. מה זה אומר שכתובות במערכת מיוצגות בגודל 32bits? זה אומר שכל רשומה בpage table בגודל 32bits , כי היא צריכה לייצג את הכתובות של הframe שלי. ז"א שנצטרך 4 בתים בשביל כל מצביע כזה. בנוסף גודל הpage הוא 4K, זה כמה אני יכול להכניס בכל page כזה, מבחינת אכסון. כל table תופסת בדיוק page אחד שזה בדיוק 4K. ה 4K של הטבלה הראשית מחולק חצי חצי בין מצביעים "מהירים" ו"נורמלים". *עד כה זה היה הסבר של השאלה *המרות חשובות: כשרושמים לנו 4K מתכוונים ל 4KB שזה 4096B. 32bit שווה 4B תשובות: א. את B4096 נחלק לfast ו normal אז יהיה B2048 לfast. אבל המצביע הוא בגודל 4 בתים (נתון) אזי 2048 לחלק ל4 :512 מצביעים! ולכן יש 512 מסוג fast pages. (512 זה בעצם 2 בחזקת 9) ב. יש 2 בחזקת 9 מצביעים (כמו מקודם) שכל אחד מהם מצביע על טבלה ! (כעת אנחנו בnormal pages) שבכל טבלה יש גם מצביעים, כמה מצביעים יש בכל טבלה? גודל הטבלה הוא בגודל 4KB, וכל מצביע בכל 4B אזי יש 1K מצביעים שזה 1024 מצביעים שזה 2בחזקת 10 כלומר: 2בחזקת 9 כפול 2 בחזקת 10 זה 2בחזקת 19 מצביעים, שזה אומר 2 בחזקת 19 normal pages. ג. מה זה גודל מרחב הכתובות הוירטואלי בבתים ? זה בעצם כמה כתובות יש לי במרחב הלוגי שלי, זה כמו לבוא ולשאול כמה pages יש לי לתהליך, כל page כזה מייצג לי 4096 בתים.אז סהכ כמות הזכרון שיש לי לתהליך: (מספר הfast pages+ #normal pages#)*page size. את #normal pages ו #fast pages יש לנו מהסעיפים הקודמים, הpage size זה 4096 =2 בחזקת 12 סהכ: 2בחזקת 21+ 2 בחזקת 31. ד. hit ratio של TLB זה אחוז הפעמים שניגשתי ל TLB ומצאתי שם את מה שחיפשתי. ז"א ב90% מהמקרים היה לי TLB hit ורק ב10% היה לי TLB miss. הeat זה התוחלת של הזמן שלוקח לי להגיע לתא זכרון. בtwo page level סטדרנטי כל המצביעים היו מצביעים לטבלאות (כולם היו normal pages) ואז היו לנו (2בחזקת 19 כפול 2)- דפים , שזה 2בחזקת 20. לעומת איך שזה עכשיו שכעת הפסדנו המון מקום מהמרחב הלוגי של התהליך. אז איך שיפרנו את eat באמצעות השיטה החדשה? שאלו על יחס אז צריך לחלק פה משהו. צריך לחלק את הeat בשיטה הרגילה עם הeat של השיטה החדשה. איפה יהיה eat יותר גדול ? כמובן שבשיטה החדשה, כי יהיה לנו את הTLB וזה קיצר נגיעה בזכרון. בtwo level רגיל, יהיו 3 נגיעות בזכרון כי הולכים פעם אחת לטבלה הראשית, ממנה לטבלה משנית ואז לזכרון עצמו, אבל יש לנו TLB עם a=0.9, כלומר ב90% מהמקרים יש לנו 1 (כי עדיין צריך לגעת בזכרון) אז ב90% יהיה 1 וב10% מהמקרים יהיה 3 נגיעות. בtwo level החדש, ב90% מהמקרים נגיעה 1 נשאר אותו דבר, וב10% מהמקרים זה מתפצל ל2 חלקים, או 2 או 3 כלומר ב5% זה יהיה 2 (עבור fast pages) וב5% זה יהיה 3 נגיעות בזכרון (עבור normal pages) סיכום ממצאים: אם זה בTLB- נגיעה אחת בזכרון אם זה לא בTLB- וזה normal page- זה 3 נגיעות בזכרון אם זה לא בTLB- וזה fast page- זה 2 נגיעות בזכרון (מהטבלה הראשית לזכרון עצמו) כעת ניתן לחשב את הeat לכל אחת מן השיטות (לא לגמרי הבנתי את החישוב כנראה שצריך להוסיף פה משקלים ) * סהכ הרעיון של דני לא משהו, הוא משפר בממש קצת

מהו התירון בשימוש בIndexed Allocation? א. אין External Fragmantation ב. אין Random Access ג. יש Internal Fragmantation ד. יש Thrashing

* indexed allocation זה רק בניהול קבצים. תשובה: א' סעיפים ב' ג' וד' הם בכלל חסרונות. מה גם שיש קצת random access. אז סעיף ב' בכלל שיקרי.

אלגוריתם round robin מומש במערכת הפעלה מסוימת כך שהכניסיות בready queue הם למעשה מצביעים לPCBs מה יהיה האפקט של שני מבציעים שיצביעו על אותו תהליך בread queue. מה הם היתרונות והחסרונות של מימוש מסוג זה? כיצד ניתן לשנות את אלגוריתם הround robin הבסיסי כך שיושג אותו אפקט גם ללא המצביעים הכפולים.

*תזכורת מה זה PCB: Process control block, לכל process אנחנו מחזיקים איזשהו data strucute יחסית רזה' שמחזיק כמה נתונים שעוזרים לניהול הprocess, זה למעשה כמו התעודת זהות שלו, יש שם דברים שקשורים לschduler שלו, יש שם את התוכן של הרגיסטרים, program counter וכו'. *בround robin נזכור שאנחנו עובדים בצורה ציקלית, אנחנו כל הזמן עוברים על הready qeuue בצורה מעגלית וכל פעם לוקח איזשהו process ונותן לו זמן על גבי המעבד, קראנו לזה time quentum. כעת בשאלה, במקום שיהיה לנו את כל הprocess מסודרים בשורה, זה שיהיה מצביעים לprocess, ונוכל לשים יותר ממצביע אחד בתוך השורה. כלומר כעת התור שלי יכול להיות: 1,2,3,4,3,5,3,6,7,8,9, ז"א לprocess 3 יש 3 מצביעים, וכעת כשאני נע בצורה ציקלית על התור, מה שזה נותן זה נותן יותר עדיפות לתהליך מסוים. כשאני עושה דבר כזה אז יש לי תהליך שיש לו יותר מופעים בתור ולכן הוא מקבל את המעבד בתדירות גבוהה יותר, ובצרוה הזאת מימשתי priority יותר גבוה לprocess הזה. *יתרונות של שיטה זו: - תמיכה בתהליכים בעלי חשיבות גבוהה יותר. (הסברתי בהרחבה למעלה) חסרונות: -זה שיש process שיש להם הרבה מצביעים לעומת process שיש להם מעט מצביעים יכול לגרום לזה שתהליך יחכה ויחכה ויחכה. הרי כל היתרון של round robin זה שאנחנו מייצרים שיוויון בין תהליכים, שכל תהליך מקבל בתורו זמן מעבד, ואז יש הבטחה שהפעם הבאה שאני אקבל את המעבד תהיה (n-1)*timeQuantum, אז עכשיו כבר אין את ההבטחה הזאת ותהלכים שיש להם רק מצביע אחד "יסבלו" למה זה לא יהיה באמת starvation- כי אני יודע בדיוק מתי אני אגיע לשם, יש תור מאוד ברור. בstarvation זה שכל פעם נכנס מישהו חדש ומשיג אותי. פה גם אם מגיע מישהו חדש הוא נכנס בתור, הוא לא יכנס לפניי. *כיצד נשנה את הround robin הבסיסי כדי שיושג אותו אפקט גם ללא מצביעים כפולים: יש המון תשובות אפשריות, - להשתמש בשני סוגים של time quantum, ואז במקום לתת עוד מצביע אני פשוט אכפיל את הtime quantum לפי הpriority של התהליך. שוב, אנחנו נאבד את השיווין שהוא כל המהות של round robin.

להלן רצף בקשות לבלוקים (על פי ה- cylinders בו הם נמצאים) המגיעות לדיסק: 10,22,20,2,40,6,38. בהנחה שראש הדיסק נמצא כרגע מעל cylinder 20, ומשך מעבר cylinder הוא 6 מילישניות, מהו רצף הקריאות שיבוצע בפועל , ומהו המשך הכולל לשירות הבקשות, אם משתמשים בשיטה: - First come First-served -Shortest Seek Time First - SCAN (כיוון תנועה התחלתי לסוף הדיסק)

- First come First-served: הסדר יהיה: 10,22,20,2,40,6,38 ראש הדיסק נמצא ככרגע מעל cylinde 20. צריך לסכום: 10+12+2+18+38+34+38 = 146 cylinders, (סכמנו את כמה הראש זז כדי להגיע לכל מקום דרוש בדיסק). משך מעבר cylinder הוא 6 מילישניות, כלומר 146*6= 876 מילישניות. * נצפה שהשיטות הבאות ישפרו ולא יעשו את המספר הזה. זה לרוב היותר מדויק. בשיטות אחרות אנחנו מניחים הנחות פחות מציאותיות. -Shortest Seek Time First: ראש הדיסק נמצא ככרגע מעל cylinde 20. הסדר יהיה: 20,22,10,6,2,38,40. צריך לסכום: 0+2+12+4+4+36+2 =60 cylinders. משך מעבר cylinder הוא 6 מילישניות, כלומר 6*60 = 360 מילישניות. SCAN: נזכיר: מגיע עד הטבעת הקיצונית ונותן שירות לכל מי שהיה בדרך, ואז עד הטבעת הקיצונית הקיצונית בצד השני. כמו מעלית שבת. הסדר יהיה: 20,22,38,40,10,6,2 צריך לסכום: 0+2+16+2+30+4+4= 58 cylinders. משך מעבר cylinder הוא 6 מילישניות, כלומור :58*6= 348 מילישניות. *אמורים ללכת בשיטה זו עד הסוף, זה חסר פה בשאלה אנחנו כאילו מניחים שהסוף זה 0 ו 40.

מה הם שלושת התפקידים העיקרייים של מערכת ההפעלה בכל הקשור לmemory managment?

- לעקוב אחר אלו חלקים בזכרון נמצאים כרגע בשימוש וע"י אלו תהליכים. - להחליט אלו תהליכים יש להעלות לזכרון כאשר מתפנה זיכרון. (מבוצע ע"י הlong time schdeuler) -הקצאה של זיכרון לתהליכים ככל הנדרש ו"איסוף" הזכרון של תהליכים שסיימו את פעולתם. -הגנה על הזיכרון של תהליכים, תרגום מכתובות וירטואלית לפיזית

מהן הפעולות שמבצעת מערכת ההפעלה בעת שהמשתמש הקליד: rm file.txt במערכות מבוססות UNIX? תאר בחלוקה לשלבים, לפי הסדר. יש להתייחס לכל הפעולות שמבצעת מערכת ההפעלה עד שהפעולה הושלמה ואין צורך להתייחס למצבי שגיאה.

-Search for a file called rm - load file into memory - Exexcute ot with the parameter file.txt - במהלך ההפעלה גישה למערכת הקבצים וטיפול באמצעות system call הרלוונטי - בסוף ההרצה ביצוע system call של exit() ואיסוף המשאבים (כלומר הקובץ כבר לא open file).

ברשותך מערכת מחשב עם כמות קבועה של זכרון פיזי, העושה שימוש בזכורן וירטואלי. א.- האם ייתכן שבאמצעות הכפלת גודל הpage יקטן מספר הpage faults? אם כן תאר כיצד, אם לא, הסבר מדוע. - האם ייתכן שבאמצעות הקטנת גודל הpage לכדי מחצית, יקטן מספר הpage faults? אם כן תאר כיצד, אם לא, הסבר מדוע. ב. חווה דעתך על הקביעה הבאה: בניהול זיכרון על בסיס סגמנטים אנו מצפים למצוא פחות internal fragmentaiton לעומת שימוש בשיטת הpaging הסטנדרטית, בעוד שבשיטת הPaging הסטנדרטית אנו מצפים למצוא פחות External fragmatnation מאשר בניהול על פי סגמנטים. הקביעה נכונה / לא נכונה? הסבר

-כן. מה הכוונה הכפלת גודל הpage ? אם מקודם הוא היה 2KB עכשיו הוא יהיה 4KB. כמות הpage faults תקטן כי אומנם יהיה הfaults של הכניסה הראשונית לזכרון ואם יש לי פחות כאלה אז הקטנו את כמות הpage fautls. (אם אני מבין נכון אז כאילו מכניסים יותר מידע לכל page, כלומר נוכל להכניס יותר ייחודיים במכה ולהפטר מהם מהר) -כן. במקרים שבהם הלוקאליטי מפוזר על פני מספר רב של pages, כאשר רק חלק מכל page משויך למעשה ללוקאליטי הרי שיש יותר סיכוי שבזכרון הפיזי תשמר הלוקאליטי כולה. (לא ברור) *מה שמשחק פה תפקיד זה ה"ייתכן" ב.נכונה. בשימוש בסגמנטים ניתן להקצות את הגודל המדויק של הסגמנט על פי האלוקציה המבוקשת ע"י התהליך, כל זמן שאכן יש לנו זיכרון רציף מספיק. מנגד, מכיוון שהזכרון לכל סגמנט צריך להיות רציף, שיטת הסגמנטים סובלת מexternal fragmentation, שכן הרבה מאוד סגמנטים רציפים בגודל משתנה מוקצים לאורך זמן. שיטת הpaging מאפשרת הקצאה לאיזורי זכרון שאינם רציפים (סותמת חורים) אולם בגודל קבוע. אי הרציפות והגודל הקבוע של ההקצאה מאפשרים להשתמש בכל איזור פנוי בזכרון ולכן לא קיימת extrnal fragmantation. אולם, מכיוון שההקצאה היא תמיד במכפלות של גודל page, לעיתים קורובות לא נעשה שימוש בכל גודל הpage מה שמביא לinternal fragmentation.

הסבר Thrashing: (לא ממבחן, זה בעיקר בשבילי, תשובה מוויקפדיה)

In computer science, thrashing occurs when a computer's virtual memory resources are overused, leading to a constant state of paging and page faults, inhibiting most application-level processing.[1] This causes the performance of the computer to degrade or collapse. The situation can continue indefinitely until either the user closes some running applications or the active processes free up additional virtual memory resources. After completing initialization, most programs operate on a small number of code and data pages compared to the total memory the program requires. The pages most frequently accessed are called the working set. When the working set is a small percentage of the system's total number of pages, virtual memory systems work most efficiently and an insignificant amount of computing is spent resolving page faults. As the working set grows, resolving page faults remains manageable until the growth reaches a critical point. Then faults go up dramatically and the time spent resolving them overwhelms time spent on the computing the program was written to do. This condition is referred to as thrashing. Thrashing occurs on a program that works with huge data structures, as its large working set causes continual page faults that drastically slow down the system. Satisfying page faults may require freeing pages that will soon have to be re-read from disk.

נתונה מערכת מחשב העובדת עם demand paging בה ה degree of multiprogramming מקובעת כרגע ל-4. במידה ובמדידת ניצולת ה CPU וניצולת הpaging disk האחרונות שבוצעו התקבלו הנתונים הבאים, האם תוכלי לתאר מה בדיוק קורה במערכת? האם הגדלת הdegree of multiprogramming תסייע להגדלת ניצלות הCPU? - ניצולת הCPU היא 13%, ניצולת הדיסק 97%. - ניצולת הCPU היא 87%, ניצולת הדיסק 3%. - ניצולת הCPU היא 13%, ניצולת הדיסק 3%.

The degree of multiprogramming describes the maximum number of processes that a single-processor system can accommodate efficiently. demand paging- is a method of virtual memory management. In a system that uses demand paging, the operating system copies a disk page into physical memory only if an attempt is made to access it and that page is not already in memory. * באופן כללי אם נגדיל את ה degree of multiprogramming זה יגדיל את ניצילות המעבד, זאת הדרך להגדיל ניצולות מעבד, ככל שיהיה יותר תהליכים במערכת אז כשהם ילכו לIO אז יהיה מי שיתפוס את המעבד, זה לא מתקיים בthrashing - למרות שאני מוסיף עוד תהליך לא רק שאני לא משפר אלא אני הופך את זה ליותר גרוע (כי התהליך הנוסף יקח חלק מהזכרון של התהליכים האחרים ואז תהליך שבמילא לא הצליח להחזק את הלוקאליטי שלו המצב שלו יהיה עוד יותר גרוע והמצב רק ילך ויעשה גרוע יותר). המקרה הראשון: כנראה אנחנו נמצאים בthrashing, כי אני כל הזמן מביא pages לזכרון (ניצולת הדיסק גבוהה) אבל ניצולת המעבד לא גבוהה, היא נמוכה. האם זה שנוסיף עוד תהליך, כלומר נגדיל את ה degree of multiprogramming, זה ישפר את את ניצלות המעבד? לא, כי אנחנו במצב של thrashing זה רק יעשה יותר רע. המצב השני: מצב מאוד בריא וטוב, אני גם מנצל את המעבד וגם אין לי Page faults. האם זה שנוסיף עוד תהליך, כלומר נגדיל את ה degree of multiprogramming, זה ישפר את את ניצלות המעבד? לא חייב, כי אנחנו גם ככה בניצולת גבוהה של המעבד. עדיף לא לגעת. המצב השלישי: גם כן מצב מאוד בריא וטוב, יש לנו ניצולות דיסק נמוכה, וניצלות מעבד לא גבוהה.אין לנו כמעט page faults. במצב זה בהחלט כדאי לנו להגדיל את ה degree of multiprogramming.

מה החסרון העיקרי של SJF ביחס לPriority schduling ?

ב SJF צריך לדע את זמני ה burst ! זה לא כזה פשוט, צריך מנגנונים מתאימים.

הניח שיש לך page refernce string לתהליך שרץ במערכת עם m פריימים ושכל הפריימים ריקים בתחילת הריצה. ה- page refernce string הוא באורך p, עם n דפים ייחודיים (unique) המופיעים בו. התהליך רץ ללא הפרעה. עבור כל אלגוריתם page replacment (למעט אופטימלי) מהו החסם התחתון ומהו החסון העליות על כמות הpage fautls?

page refernce string= זה רצף בקשות של תהליכים לpages כמו שראינו בשאלה 73. המינימום page faults שיהיה לנו זה n, כי אמרו שיש n דפים ייחודים, ובהתחלה הפריים שלנו ריק. אז במקרה הטוב נכניס את כל הייחודיים לפריים שלנו ואז או שנסיים לרוץ על p או שזה יסתדר טוב ככה שלא יהיה page fautls כלל. אף פעם לא יהיה פחות page faults מ n (זה כולל גם את האופטימלי) כעת במקרה הגרוע, צריך להפריד למקרים, כאשר m קטן מ-n, וכאשר m גדול שווה מn. -כאשר m גדול שווה מ-n אז גם במקרה הגרוע יהיה n -לpage fautls (כי פשוט נכניס את כל המספרים הייחודיים לפריים שלנו ואז לא יהיו יותר Page faults). - כאשר m קטן מ-n,אז החסום העליון יהיה p. (לא נוכל לעשות חסם עליון באופטימלי)

מהם שלושת התפקידים העיקריים של מערכת ההפעלה בכל הקשור ל secondary storage mangement?

secondary storage- דיסק, CD ROM- כל מה שאני יכול לאחסן בו מידע והוא לא זיכרון. מה הם 3 התפקידים העיקריים של מ.ה בהקשר הזה: - ניהול המקום הפנוי (למשל לדעת איזה חלקים בדיסק הם פנויים ואיזה מוקצים) - הקצאה של שטח אחסון - disk schduling.

תהליך מבצע את הגישות הבאות לpages: 1,2,3,2,4,2,1,5,6,2,3,7,4,5,6,3,7,2,6 כמה page faults צפויים להתרחש עובר כל אחד מאלגורתמי ההחלפה להלן? הנח כי בסך הכל קיבולת הזכרון היא 5 frames. זכור כי כל הframes ריקים בהתחלה, כך שגם הקריאה הראשונה לכל page תייצר page fault. א. לפי LRU ב. Second Chance (הנח שלאחר כל החלפה ובעת קריאה של page לזכרון מקבל הrefernce bit של ה frame שנכנס ערך 1 והמצביע עובר ל frame הבא בזכרון ג. Optimal

א. 12. אפשר לשחק עם זה ולראות, תוודא שאתה עושה כמו שצריך את ה-5 שיושבים בframes ויודע להגיד מי ה LRU. דיי פשוט ב. ניראה לי יוצא 10 ניתן לראות ב2:00:45 את הריצה של זה עם דודי. לא הכי ברור איך זה עובד. ניסיתי על טיוטה זה לא לסיכום פה ג.8 optimal= מביא למינימום האפשרי של page faults . מבין כל הדפים שנמצאים בעתיד במחרוזת, מי ההופעה האשונה שלו היא הכי מאוחרת. נותן חסם תחתון שאין בר השגה, זה אלגוריתם תיאורטי. זה דווקא ממש קל רק לעקוב אחרי ההוראות.

אחת האופציות במערכות mainframe היא להגביל את מספר התהליכים שיכולים לשהות בו זמנית במערכת. סמן עבור כל אחד מהמדדים להלן האם ערכו יעלה/ ירד במידה ותופעל אופציה זו: א. הזכרון המוקצה לכל תהליך במערכת _____. ב. מספר התהליכים במצב runnable ______. ג. מספר הpage faults ______. ד. הscheduling overhead________.

א. יגדל. יהיו פחות תהליכים, כל תהליך יקבל יותר. ב. יש כאן tradeoff בין כמות תהליכים סה"כ שהם פוטנציל לrunning לבין גודל התורים על הIO. מצב runnable זה אומר שהם יכולים לרוץ אם נותנים להם (הם בready queue). הנטייה שלנו היא לבוא ולהגיד "יגדל" אבל למה יגדל- כי לכאורה התורים על הIO יהיו יותר קטנים אז יהיו תהליכים שיוכלים לחזור מIO ולרוץ, אבל מצד שני מלכתחילה יש פחות תהליכים, ואז אולי אני אמצא את עצמי אולי ביותר מצבים שכרגע כולם ב IO ואין את מי שיכול לרוץ (בטח אם יש קשר בין תהליכים). ג. יקטן. הוא יקטן אותה סיבה שהזכרון לכל תהליך יגדל, ואז נוכל לשמור יותר pages בזכרון. ד. יקטן. מה זה הscheduling overhead? המשאבים שצריך להקצות לscheduler בשביל שיוכל לעשות מה שהוא צריך לעשות. יש לו פחות תהליכים לטפל בהם ולכן הscheduling overhead יקטן.

סמן בעיגול את התשובה הנכונה: א.מצב של TLB miss (רשומת מיפוי הpage המבוקש איננה מצויה בטבלה ה TLB) תמיד/ לעולם לא/ לפעמים , גורר קריאה של frame מהדיסק. ב. פריסת הvirtual pages של virtual address space היא תמיד/ לעולם לא/ לפעמים, רציפה במרחב הזכרון הפיזי. ג.מבין 3 הגישות שנלמדו, הגישה שמיישם Banker Algorithm לטיפול בדדלוק היא: ignore/ recover/ avoidance. ד. אלו מבין מנגנוני הscheduling הבאים יכול להוביל לstarvation (יש יותר מתשובה אחת): FIFO/ SJF/ Prioriy/ RR? ה. בתוכנית שיש בה race condition תמיד / לעולם לא/ לעיתים, תיגרם פגיעה באמינות הנתונים או התנהגות לא תקינה. ו. במערכת שבה מתקיימים כל ארבעת תנאי הדדלוק: תמיד / לעולם לא/ לעיתים, ייוצר מצב של דדלוק. ז. שני המרכיבים של כתובת וירטואלית בהם משתמשים בsemented virtual address הם: ? ח. במערכת בה רצים ברגע נתון מספר תהליכים, תהליך שמבצע (או נמצא במצב) של thrashing יוגדר כתהליך IO bound / CPU bound , וינצל את הtime slice שלו לעיתים רחוקות/ לעיתים קרובות.

א. לפעמים. זה רשומה מסוימת לא הייתה בTLB לא באמת מחייב שהרשומה לא בזכרון (אמרנו שהTLB זה סוג של קאש שעוזר לזרז חיפוש דפים בזכרון) רק במקרה הגרוע שבו הדרשומה גם לא בזכרון אז נצטרך ללכת לדיסק. ב. לפעמים. יש את מרחב הזכרון הלוגי, שהוא כמובן רציף (זה כל הרעיון במרחב זכרון לוגי, זה הזכרון הווירטואלי שבדיסק), שואלים אותנו האם שנלך להסתכל על הpages שלנו בframe שמוקצים בזכרון האם נמצא אותם בצורה רציפה בזכרון או שהם לא יהיו בצורה רציפה בזכרון. בעקרון כל הרעיון של הpages זה שנוכל לשים בזכרון גם בצורה לא רציפה, אבל יכול להיות סיטואציה שבמקרה היה מקום באופן רציף שם, הpages רק מאפשר לנו גם למלא חורים אבל יש מצב שבמקרה תהיה רציפות (קצת קשה היה להבין מהשאלה את העניין הזה שהתכוונו לדפים שיושבים בזכרון הפיזי) *צריך להבין שעובדים בשיטה של הקצאת זכרון של pages. הpage table ממפה בין הדפים בזכרון הווירטואלי לפיזי. ג. avoidance. לא מתמקדים בזה פה אבל יש המון כרטיסיות על באנקר למקרה ואתה צריך תזכורת. ד. SJF, Priority. החארים לא יובילו אותנו לstarvation כי אף אחד לא יכול לעקוף אותי. ה. לעיתים. אין הסבר של דודי, אני מאמין שזה נובע בגלל שכאשר יש תחרות על משאבים זה פותח אופציות להתנהגות לא תקינה, לא מחייב. ו. לעיתים. כדי שיהיה דדלוק כל הארבע חייבים חייבים לקרות, אבל זה לא מחייב שיקרה. אם אחד מהם לא היה קורה, היה ניתן לסמן את לעולם לא. ז.segment number ו offset. *לחזור על הנושא הזה של segmented virutal address. לא יושב מספיק. הסגמנט זה מספר הסגמנט, אני אלך לטבלת הסגמנטים ושם אני אמצא את מקום ההתחלה. הoffset אומר לנו כמה תאי זכרון מתחילת הסגמנט אני צריך לצעוד בזכרון הפיזי. ח.IO bound, לעיתים רחוקות. הוא יוגדר כ IO bound כי הוא כל הזמן מביא דברים מהזכרון הווירטואלי הוא כל הזמן בIO. לעיתים רחוקות כי כל פעם הוא צריך לחזור מחדש ולעשות restart להוראות שלו ולהתחיל מחדש את הניצול שלו של הtime slice.

יש פה שאלה נחמדה על נטלי וטניס בערך ב3:00:00 מתחיל. א. במידה והבשרת המועדון נעשה שימוש בpriority schduling, תחת אלו תנאים היה עלול להיווצר deadlock אם משתמשים בפתרון של נטלי? נמק והסבר. (הפתרון של נטלי זה להשתמש במנעול פשוט) ב. נטלי מציעה להעביר את השרת לתזמון על בסיס מנגנון round robin. האם אכן הבעיה תיפתר בצורה זו? במידה וכן נמק, במידה ולא הסבר מה עוד צריך להתקיים בשביל שאכן תהווה פתרון.

א.אם ה priority schduling הוא preemptiove ואכן יש priorites שונים לתהליכים שונים, הרי שיתכן ותהליך עם priority נמוך השיג את הנעילה, ושהוא ב-critical section שלו הגיע תהליך עם priority יותר גבוה ויחליף אותו, מבלי שהוא ישחרר את המנעול. אז התהליך עם הפריוריטי הנמוך הוחלף לפני שהוא שחרר את המנעול, והתהליך עם הפריוריטי הגבוה תקוע כי הוא מחכה שישחררו לו את המנעול, משמע שניהם תקועים. זה קצת כמו priority inversion רק עם 2 תהליכים במקום 3. ב.בוודאי שכן, בround robin אין אפילו starvation אז אין גם מצב של דדלוק.

הוצע לך לרכוש שרת מסוג חדש, שבו מערכת הvirtual memory מאפשרת להוסיף זכרון פיזי תוך כדי ריצה, ללא צורך בעצירת השרת. הקף בעיגול את התשובות הנכונות: תוספת זכרון פיזי תוך כדי ריצה א. תגדיל/ תקטין/ תותיר ללא שינוי את הworking set וב. תגדיל/ תקטין/ תותיר ללא שינוי את זמן הריצה של התהליכים הרצים במערכת? הסבר.

א.תותיר ללא שינוי. הworking set זה קוד כתוב, הוא לא תלוי בזכרון שמוקצה, הוא מנסה למדוד את הלוקאליטי, איך הוא מודד את הלוקאליטי? הוא מזיז איזשהו חלון על פני ציר הזמן ובודק כמה page ייחודיים יש לנו. אז זה לא משנה אם ישלנו frame אחד לתהליך או 1000 frame לתהליך, המדידה עצמה היא מדידה בהתאם להוראות, זה לא משנה כמה frame נתת לי, יותר frame זה יקטין את כמות הpage fault אבל זה לא ישנה את אופן המדידה של הworking set. ב.תקטין. כמובן שיקטין כי ככל שיהיה יותר זכרון לתהליכים יהיה להם פחות page faults ולכן זמן הריצה שלהם יקטן.

חמישה תהליכים ממתנים למעבד. הburst time שלהם הוא 5,3,6,9,X. באיזה סדר יש להריץ את התהליכים על מנת למזער את הwaiting time הממוצע. נמק.

אז כמובן בשביל לקבל minimum average waiting time עלינו לחתור להשתמש כמה שיותר הshortest burst first SJF. אם היינו יודעים מה זה X זה היה קל, הסדר היה פשוט מהקטן לגבוה. אבל בגלל שאנחנו לא יודעים את X זה קצת מבלבל. פתרון: לחלק למקרים, X יכול להיות בין כל מספר שם. שאלה מתנה.

בשאלה זו יש לבטא את כל התשובות כחזקות של 2. במערכת 64bit (הייצוג של כתובות בזכרון) מסויימת מחולקת כתובת הזכרון הורטואלי בהתאם לסכמה הבאה (3:04:10) א. מהו גודל הpage במערכת זו בבתים, הסבר? ב. מהו מספר הסגמנטים המקסימלי שיכולים להיות לתהליך? נמק. ג. הנח כי כל הטבלאות המשמשות את הכתובת הוירטואלית (מלבד טבלת הסגמנטים) הן בגודל של page ( על מנת שניתן יהיה לאחסן אותן בנוחות בדיסק במידת הצורך) מהו גודל כל רשומה בpage table . נמק. ד. מהו הזכרון המקסימלי שניתן להקצות לסגמנט בארכיטקטורה המתוארת? מהו ה overhead מבחינת כמות הזכרון המבוזבז לצורך הטבלאות התומכות בpaging הנדרש לצורך ניהול זכרון זה? נמק.

אנחנו מבינים שמדובר פה בMULTICS, כלומר סגמנטים שמיוצגים באמצעות pages. אנחנו מבינים ש14 הביטים האחרונים מייצגים את המיקום בתוך הpage. 4 האלמנטים באמצע זה ההיררכיה של הpages שמממשים לי את הסגמנט הספציפי. א. 2 בחזקת 14, כי אם הoffset בתוך הpage מיוצג באמצעות 14 ביטים אז זה אומר שגודל הוא 2 בחזקת 14. זה 16KB ב.מספרי הסגמנטים בעמודה השמאלית ביותר בטבלה. ולכן 2 בחזקת 6 יכולים להיות. ג. צריך לקחת את 2בחזקת 14 (שזה גודל הpage) ומכיוון שאני יודע שיש לי 11 ביטים לייצג את הכניסה בתוך כל אחת מהטבלאות. אז אם נחלק 2 בחזקת 14, שזה כמות הזכרון שיושב לי page , מחלק ב2 בחזקת 11, שזה כמות המצביעים שיש לי בpage, נקבל 2 בחזקת 3 שזה בעצם כמות הבתים שלוקח לי לייצג מצביע. (מזכיר את השאלה של דני שהייתה לנו ששם גודל הרשומה היה 4 בתים) אז כל רשומה בpage table היא 8 בתים, כלומר 8 בתים למצביע. ד. הזכרון המקסימלי שניתן להקצות לסגמנט בארכי המתוארת: לכל סגמנט יש 2 בחזקת 11 מצביעים- כפול 2 בחזקת 11 מצביעים- כפול 2 בחזקת 11 מצביעים כפול 2 בחזקת 11 מצביעים - כפול גודל ה page שזה 2 בחזקת 14. כלומר כמות הזכרון המקסימלית לסגמנט היא 2 בחזקת 58. (שזה המון) כמה בזובז היה לנו בשביל להחזיק את כל הטבלטאות האלה שיתמכו בנו? 2^ 14 כפול ( 1 + 2^11 + 2^11*2^11 + 2^11*2^11*2^11) = הoverhead שבזבזתי על מנת לתחזק את כל המערך הזה של הזכרון.

עוד שאלה בנושא דדלוקים ב2:27:54. ניתן לראות בטבלה את ה max מיד צריך לקפות לנו לראש האלגוריתם של באנקר. יש בשאלה 5 תהליכים , 4 משאבים. אנחנו רואים בטבלה את הcurrent allocation ואת הmax need. הcurrent allocation היא הכמות מכל משאב שכרגע מוחזקת על חידי תהליך. הMax need היא הכמות עליה הצהיר כל תהליך עם יצירתו ככמות המקסימלית מכל משאב שתידרש לו במהלך הריצה. בנוסף ידוע שכמות המשאבים במערכת היא: [6,7,14,12]. א.ספיר טוענת שהמערכת איננה מצויה כרגע בדדלוק, וזאת עוד לפני שהפעילה את האלגוריתם שנלמד בכיתה לזהיוי דדלוקים. מדוע ספיר כה בטוחה בתשובתה? ב.האם יכולה ספיר להיות בטוחה שםא נעבוד לפי אלגוריתם banker נוכל להבטיח גם שהמערכת לעולם לא תיכנס בעתיד למצב של דדלוק? ג. במידה ונעבוד מנקודה זאת ואילך לפי אלגוריתם banker, האם ניתן להיענות לבקשה [0,1,0,0] המגיעה מתהליך p4? *(סעיף לא מובן, כדאי לברר בכללי על כל השאלה)ד. בהתעלם מסעיף ג', במידה ונעבוד מנקודה זאת ואילך לפי אלגוריתם banker, האם ניתן לענות לבקשה [0,1,2,0] המגעה מתהליך p2 במידה ואנו רוצים להבטיח שלא נקלע למצב של דדלוק?

אנחנו רואים בשאלה את זה שיש עמודת max ולכן מיד צריך לקפוץ לנו אלגוריתם באנקר. בעזרת הטבלה השנייה נוכל לחשב את ה available, כלומר הavaiable זה כמות המשאבים במערכת פחות current allocation. ניתן לעשות חישוב תחילי לבדיקה ולראות שסהכ הcurrent allocation לא עובר את כמות המשאבים במערכת, אחרת יש טעות בנתונים. א.התשובה מצויה בגוף השאלה. רשום בברור- "ברגע זה אף אחד מהתהליכים לא מבקש הקצאה של משאבים נוספים". מה זה אומר: זה אומר שיש לנו hold אבל אין לנו wait. כלומר הם מחזיקים משאבים אבל אף אחד לא ממתין לתהליך אחר. ב. אלגוריתם באנקר דואג שהמערכת תהיה בsafe state, ואם מישהו יבקש הקצאה של משהו אז הוא קודם יבודק שההקצאה תשאיר אותנו בsafe state, ואם לא הוא יגיד לו לחכות, אז היא יכולה להיות בטוחה שאם כל הזמן נבדוק את זה בעזרת אלגו באנקר אז המערכת לא תכנס למצב של דדלוק, אלא אם כרגע! היא לא בsafe state. אז מה צריכים לעשות? לבדוק שאנחנו כרגע נמצאים בsafe state, אם אנחנו כרגע בsafe state ונמשיך לעבוד עם אלגו באנקר אז נוכל להבטיח שהיא גם לעולם לא תכנס למצב של דדלוק. איך נבדוק שהיא בsafe state? נפעיל את האלגוריתם: בavailable יש לנו [2,1,2,0]. הneed/request: זהmax פחות current allocation: עבור p1: [0,0,2,0] עבור p2: [0.7.5.0] עבור p3: [6,6,2,2] עבור p4: [2,0,0,1] עבור p5: [0,3,2,0] אנחנו בודקים את הrequest כי זה חשוב שנדע כמה במקרה הכי גרוע משאבים נצטרך להשקיע עוד ולכן הsafe squence יהיה: נספק את p1,ניתן לראות שגם במקרה הגרוע הוא ניתן לסיפוק בעזרת המשאבים שיש לנו כבר עכשיו. הוא יסיים את עבודותו נקבל בavailable את משאביו:(המשאבים של הcurrent allocation שלו) [2,1,3,2]. כעת ניתן לספק את p4, נקבל משאביו, וכעת יהיה לנו [4,4,8,6], כעת ניתן לספק את p5, נקבל את משאביו ויהיה לנו [4,7,11,8] ונוכל בוודאות לספק את p2 או p3. ולכן קיבלנו safe sequnce, כלומר אנחנו בsafe state. ולכן כרגע המערכת לא בדדלוק ובסהכ אם היא כרגע לא בדדלוק ומעתה והלאה נשתמש באלגו באנקר משמע היא גם לא תכנס לדדלוק בעתיד אזי ניתן להגיד שספיר יכולה להבטיח את המניעה של הדדלוק. ג. מה בתכלס צריך לעשות: לעשות הקצאה בכאילו בתהליך p4 ואז להפעיל את הבדיקה של הsafe state. אבל מה עוד אמר אלגו באנקר: קודם כל תבדוק 2 תנאים: תנאי אחד- מה שמבקש התהליך לא חורג מה need שלו. (אחרת המקסימום שהוא הצהיר עליו לא מקסימום נכון) ניתן לראות בסעיף הקודם שהneed של p4 הוא [2,0,0,1] וכאן בסעיף כמה הוא מבקש: [0,1,0,0] ,ז"א שהוא לא יכול לבקש בכלל דבר כזה כי הוא חורג מהמקסימום שלו. (בR2 יש חריגה) ד. לא, אומנם הבקשה חוקית כי הדרישה של p2 היא [0,7,5,0] וכעת זה מבקש פחות, אולם אם נקצה את המשאבים לא נוכל לקבל safe sequnceשכן לא ניתן לספק את הצורך של אף משאב כעת.

מערכת paging משתמש בpages בגודל של 2KB (2048). להלן הpage table ו TLB של תהליך במערכת. (דקה 38:35) תרגם את הכתובת הלוגית 3000 לכתובת פיזית וחשב את כמות הגישות לזכרון (RAM) כולל הגישה לנתון עצמו.

בא המעבד ואמר שהוא רוצה את כתובת 3000. מה צריך לעשות? צריך לחלק 3000/2048, זה 1 ושארית. ה1 אומר page מספר 1, ניתן לראות שהוא בTLB, שהוא בframe מספר 4. Frame מספר 4 מתחיל פיזית במקום ה4*2048. לזה צריך להוסיף את השארית של החלוקה 3000/2048. 8192+ השארית, זה 9144. כמה נגיעות היה לנו בזכרון בשביל הדבר הזה? הTLB חסך לנו את הגישה ל page table אבל צריך להחשיב את הגישה לנתון עצמו שזה 1. סה"כ היה לנו גישה אחת לRAM. *הנוסחא לתרגום כתובת לוגית לכתובת פיזית היא: לבצע חלוקה בין הכתובת הלוגית לגודל הדף, נקבל שלם ושארית. את השלם נחפש בטבלה ונקח את המספר שמופיע, נסמן את המספר בnum. נעשה: שארית + num*גודל הדף = כתובת פיזית. לשארית נהוג לקרוא offset לשלם #page

במערכת מחשב 2 מעבדים (א' וב'). תהליך כלשהו רץ על מעבד א', והרצתו הופסקה עקב interrupt. במהלך ביצוע הinterrupt (ובטרם הסתיים הטיפול בו) התפנה מעבד ב' ואין כרגע תהליך אחר במערכת במצב ready. מהו היתרון המרכזי והחסרון המרכזי במעבר התהליך למעבד ב'? נמק.

באופן אידאלי יש לנו עכשיו תהליך שהיינו רוצים להעביר אותו למעבד ב', למה הוא צריך לחכות עכשיו עד שהinterrupt יסתיים ? אם נעביר אותו אז כבר שיפרנו את הנצילות של מעבד ב' כי כרגע הוא עומד idle, ולא עושה כלום, ואנחנו יודעים שאנחנו רוצים שתהיה נצילות גבוהה למערכת. זה בעצם היתרון המרכזי בלהעביר אותו למעבד ב', היעילות, המהירות, הturnaround time כלומר תוך כמה זמן נסיים את התהליך שלי והנצילות של המעבד. חסרון: התהליך שרץ על מעבד א' הוא ייצר cache ואם באמת מדובר בטיפול בinterrupt סימן שהוא יסתיים דיי מהר והוא לא יפגע יותר מדי בcache שכבר נוצר, ולכן אולי שווה להמתין ולהתעקש על מעבד א' כי אז נוכל להמשיך בלי לבנות מחדש את כל הcache שכבר בניתי. *זה כמו שעכשיו הלכת למשרד הרישוי, התחלת להסביר לפקיד שם את כל הסתבוכת שיש לך עם הרכב שלך, את כל הבלאגן. ואז לפתע הפקיד מקבל שיחת טלפון, ובן בזמן אתה קולט שהפקיד לידו התפנה האם תרצה לעבור לפקיד שהתפנה? מצד אחד אם אתה הולך לפקיד שהתפנה אתה מגדיל את הנצילות אתה לא מחכה, מישהו מטפל בך. מצד שני אם אתה עובר אליו אז כל הcache שבנית אצל הפקיד הראשון תצטרך לבנות אותו מחדש, תצטרך להתחיל ולספר מחדש הכל. מה עדיף ? אין תשובה ברורה. אם באמת הcache משמעותי, אתה יושב ומספר את הסיפור שלך כבר דקות ארוכות אז עדיף לך להמתין לפקיד עם הטלפון כדי שתוכל לחזור מאיפה שהפסקת. אם עכשיו הפקיד הולך לדבר חצי שעה בטלפון אז כדאי לך לעבור לפקיד ב'. אם פתאום פקיד א' לא סתם בInterrupt קטן אלא בcontext switch אז בוודאי ששווה לעבור לפקיד ב'. *נשים לב שגם אם נשארנו במעבד א' עדיין יהיה context switch (נצטרך להזכיר לו על מה דיברנו) ולכן זאת לא תשובה טובה ל"חסרון להשאר בפקיד א'"

מדוע במערכת ההפעלה linux בקבצים גדולים מאוד (מספר GBs), זמן הגישה הראשונה לסוף הקובץ הינו ארוך יותר מאשר זמן הגישה הראשונה לתחילת הקובץ?

בלינוקס יש לנו את ההיררכיה שאנחנו מכירים. אם אני ניגש לתחילת הקובץ, אז יש לנו מצביעים ישירים לקובץ, אם אני ניגש לסוף הקובץ והקובץ מאוד גדול אז כנראה שנצטרך לקרוא בלוק ואז עוד בלוק (שכל קריאה כזאת זה פעולת IO ) ורק אחרי כמה בלוקים נגיע לבלוק מידע שאנחנו רוצים. למה חשוב בשאלה שזאת הגישה הראשונה? כי מרגע שקראתי את הדברים האלה אז הם בזכרון הם בopen file שלנו, ואז בגישה השנייה נדע את זה ולא נצטרך לעבור מסע מפרך בבלוקים הרחוקים. זה סוג של קאשינג לדיסק. * שווה לראות את הדיאגרמה של דודי אם לא ברור בדקה 2:36:30

במערכות מחשב בעולם האמיתי, הן המשאבים והן הדרישות של התהליכים למשאבים אינם קבועים לאורך זמן. משאבים מסוימים מוחלפים או מושבתים עקב תקלות, ומשאבים נוספים נקנים ומוספים למערכת. במידה וdeadlocks במערכת מבוקרים על ידי baker's algorithm, אלו מהשינויים הבאים ניתנים לביצוע בבטחה (מבלי לייצר אפשרות לdeadlock) ותחת אילו אילוצים ? - שינויים בavailable -שינויים בMAX - שינויים במספר התהליכים

במערכת שאנחנו עובדים עליה יש כרגע Banker's algorithm משמע תהיה מניעה של דדלוקים. איזה שינויים נוכל לבצע בצורה בטוחה- בלי לייצר אפשרות לדדלוק , תחת אילו אילוצים. Available- כמה נשאר שלא מוקצה כרגע Max- כמה במקסימום רוצה כל תהליך מכל משאב -Allocation - כמה הוא משתמש כרגע Need- זה Max פחות Allocation, אומר לנו כמה הוא עלול להצטרך בשביל להגיע למקסימום שהוא הצהיר עליו. שינויים בavailable: הגדלה: כעת נניח שאנחנו מגדילים את הavailable,למשל הלכתי וקניתי עוד משאבים והוספתי אותם למערכת האם מותר לי לעשות את זה ואני לא אצטרך לדאוג שיהיה לי דדלוק או שאסור לי לעשות את זה כי אני עובד עם האלגוריתם של באנקר ואני פוחד שיהיה לי דדלוק? הגדלה של available תמיד מותרת, כי אם אני מגדיל את המשאבים שיש לי, אם הייתי בsafe state מקודם גם עכשיו בהכרח אני אהיה בsafe state. אני רק אהיה יותר "עשיר". הקטנה: רק אם המערכת לאחר ההקטנה נשארת בsafe state, מותר לי להקטין. אם היא נשארה בsafe state אני אוכל להמשיך ולעבוד עם האלגוריתם של באנקר, אבל אם יצאתי עכשיו מsafe state אז אני עלול להתקל בדדלוק. שינויים בMax: הגדלה: חשוב להבין- הmax פחות allocation נותן לי את הneed, ואת הneed אני בודק מול ה available, ןאם אני מצליח לעשות את זה אז אני מצליח למצוא safe sequnce. ההגדלה של הmax יש לה את אותה משמעות כמו הקטנה הavailable. היכולת שלי לבוא ולספק את הneed עם הavailable היא תקטן כתואצה מהגדלת הmax. כלומר max גדל- need גדל. ואז קשה יותר לספק את הneed. סהכ תשובה: הגדלת max אפשרית רק אם המערכת לאחר ההגדלה נשארת בsafe state. הקטנה: הקטנה אפשרית תמיד, זה מאותם נימוקים של הגדלת available. שינויים במספר התהליכים: הגדלה: הגדלה של מספר תהליכים תמיד תשאיר בsafe state, כי אם יבוא תהליך חדש, האינטואציה תגיד- הוא בטח ירצה עוד משאבים וזה יקשה, אבל התהליך החדש שנוצר בזמן היצירה שלו כשהוא נכנס לready queue, ומכיוון שאנו עובדים עם banker algo , אז אנו יודעים שדרך הבקשה שלו למשאבים אנחנו נגיד לו "הלו תמתין" יכול להיות שהוא יוציא אותי מsafe state אז נגיד לו לחכות. כלומר גם אם אנו מגדילים את כמות התהליכים אין לי בעיה מבחינת הsafe state , כי עצם ההכנה של תהליך חדש לא אומרת שנתתי לו משאבים עדיין, יכול להיות שהוא יצטרך לחכות. הקטנה: תמיד, זה תמיד אפשרי כי מן הסתם אם נוריד תהליך אז ה need של אותו תהליך נעלם , אני בכלל לא אצטרך לשבץ אותו בsafe sequnce שאני מייצר אז החיים שלי רק יהיו יותר פשוטים מהקטנה של תהליך.

שני תהליכים נוצרים באותה מערכת מחשב בדיוק באותו זמן ועל בסיס אותה program. ידוע שאחד מהם נמצא כרגע במצב ready ואילו השני בwaiting. כמו כן ידוע שאחד מבין השניים עדיין לא קיבל זמן על המעבד מאז שנוצר- מי מבין שני התהליכים הוא אותו תהליך?

בשביל להגיע לwaiting הוא חייב להיות קודם בrunning. ולכן התהליך שהיה בwaiting בהכרח כבר קיבל זמן מעבד. (הוא יצא לI/O) בניגוד לשני שיכול להיות שהוא במצב ready כי הוא רק נכנס לready queue אבל לא בטוח שהוא קיבל זמן מעבד.

shared memory ו message passing הן שתי שיטות לinterprocess ו communication. מהם ההבדלים בין השיטות ומהם היתרונות של כל שיטה?

הבדלים: בshared memory אנחנו קוראים וכותבים ישירות מאיזשהו אזור בזכרון משותף. ב message passing אין לנו את השיתוף הזה אלא זה מנגנון יעודי של מ.ה שנותן לנו להעביר את ההודעות ומנהלת את זה. *(כמו להגיד שיש לנו את לוח המודעות מתחת לבניין, כל מה שאני אכתוב, כל מי שבבניין יוכל לקרוא, לעומת זאת יש לי את הדואר אני גם יכול לשלוח מכתב לשכן שלי ואז מי שינהל את כל הסיפור הזה זה הדואר, אני אלך לדואר אשלח את המעטפה, היא תגיעה אל השכן, השכן יקבל את ההודעה.) יתרונות shared memory: - מהירות - קצב כתיבה וקריאה מהיר יתרונות של message passing: - מישהו מבצע את זה בשבילנו, מובטח שיהיה פחות טעויות, (לא צריך לממש בעצמי מנגנון של סינכורנזציה שיש לי בshared memory) * למשל בלוח מודעות שיש בבניין, אני יכול לכתוב משהו, ואז יכול לבוא שכן ולמחוק את מה שאני כתבתי ולכתוב משהו אחר, ואין לי מנגנון לוודא שבאמת מי שהיה אמור לקרוא את מה שכתבתי באמת קרא לפני שהדבר הזה נמחק)

שלושה תהליכים חולקים בינהם 4 יחידות משאב להן ניתן לבצע reserve או release. כל אחד מהתהליכים צריך מקסימום שתי יחידות על מנת להשלים את משימתו. האם יכול להיווצר deadlock? במידה וכן, הדגם. במידה ולא, הוכח.

הדגמה גרפית: (כדאי להעיף עליה מבט אם אתה לא זוכר זה נחמד,דקה 2:06:55) נסמן את 3 התהליכים בעיגול ואת 4 יחידות המשאב בריבוע. מצב של דדלוק יתקיים רק אם כל יחידות המשאב הם reserved ולפחות אחד התהליכים ממתין עד אינסוף לעוד יחידות. אולם אם 4 יחידות הן reserved הרי שלפחות תהליך אחד תופס שתי יחידות, כלומר תהליך זה יוכל להשלים את משימתו ולשחרר את 2 היחידות שהוא תפס, ואז 2 התהליכים האחרים יוכלו בוודאות לבצע את משימתם (כי כעת יש 2 תהליכים שכל אחד צריך במקסימום 2 ויש 4 משאבים אז קל וחומר שהם יסתדרו) פשוט מאוד- לא יהיה דדלוק ההוכחה מוסברת.

רשום שתי סיבות נגד שימוש תכוף בthread (קרי, שימוש תכוף במספר רב של threads למשימות שונות). יש להמנע מסיבות אשר תקפות לprocess- באופן כללי יש להתמקד בthreads.

הכוונה פה , הרי אנחנו יכולים שהprocess במקום שהוא ייצא עוד thread בתוכו, הוא בעצם ייצר process בן שיעשה את אותה משימה שה thread היה אמור לעשות. אז למה אני לא הייתי רוצה להשתמש בהרבה threads ? - סינכורנזציה- כאשר אני מייצר מקביליות בהרצה אני יכול ליצור באגים, עלול להיות מצב שהסינכורנזציה לא תעבוד- אם ינסו לגשת למשאב משותף/ ינסו לעדכן משהו בזמן שthread אחר קורה. רשמי: -הthreads אומנם זולים אבל בהחלט יש להם עלות כלשהי. שימוש בהרבה threads יגרום למערכת לבצע הרבה context switching ובכך תקטן נצילות המעבד. (למרות שזה נכון באותו אופן גם לprocess אם היינו משתמשים) - שימוש בthreads רבים הופך את הסינכורנזציה לקשה ומסובכת יותר משום שכעת יש לנו מספר דברים שמבוצעים במקביל. הדבר גם מקשה על הדיבאגינג מכיוון שההרצה הופכת להיות non-deterministic ו non-reprodcuable. *בשאלה פה דודי מדבר על איזה עניין שניראה לי חשוב: אם היינו משתמשים בprocess במקום בthreads אז בעצם היינו מקבלים יותר משאבים כי לכל process היו מוקצים משאבים משלו. (דיברנו על 3 גישות לאיך נותנים משאבים process חדש: - האם זה יהיה מתוך המשאבים של הprocess אב, - האם הוא ישתמש רק בsubset של הprocess אב - האם מערכת ההפעלה תיתן לו משאבים משלו.) *אז אם נניח שמ.ה תיתן לו משאבים משלו, אז זה שהפכנו את זה לprocess במקום לthreads זה באמת עזר לנו. אגב, אם היינו עושים את זה כprocess אז גם היינו מרוויחים ברמת הschdueler, כי הוא היה מסתכל על זה ככמה process אז התידרות שהיינו מקבלים את המעבד עבור ה process שלנו הייתה יותר גבוהה, בניגוד למצב של בthreads שהם כולם מקושרים לאותו process והם צריכים להתחלק בזמן שמקבל הprocess על המעבד. סיכום קטן שלי לשאלה: למה עדיף להשתמש בprocess במקום בthreads : - עניין הדיבאגינג, מובן. - עניין ה-זה בכל זאת עולה ויש context switching, מובן - אם נשתמש בprocess במקום ב בthreads ומערכת ההפעלה תקצה לprocess משאבים משלו- נרוויח - אם נשתמש בprocess במקום ב בthreads נרוויח ברמת הschduler כי זה נותן לנו זמן מעבד רב יותר.

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

המחשב של מורן עובד עם multi level feedback queue ומשהוספנו את ההדפסות גרמנו לכך שכל הדפסה הביאה לכניסת התהליך מחדש לרמה העליונה וקבלת עדיפות על גבי הCPU. במחשב של שמעון הschduler משתמש בשיטה אחרת. חשוב להבין שהדפסה למסך היא יציאה לI/O, והחזרה ממנה מחזירה את התהליך חזרה מההתחלה לתור ולקבלת זמן מעבד חדש.

מהן הפעולות שמבצעת מערכת ההפעלה בעת שהמשתמש הקליד: rm file.txt במערכות המבוססות Unix? תאר בחלוקה לשלבים, לפי הסדר. יש להתיחס לכל הפעולות שמבצעת מערכת ההפעלה עד שהפעולה הושלמה ואין צורך להתייחס למצבי שגיאה

הסבר של דודי: השאלה מתקשרת לחומר של CLI, commnad line interperter, כלומר לקחת את הפקודה שהקליד המשתמש ולהריץ את הפקודה הזאת. ראינו 2 שיטות למימוש CLI: - שיטה אחת: שים את כל הלוגיקה של הinterperter את כל הקוד, בCLI עצמו, וכל פקודה שהמשתמש הזין נדע לאן לקפוץ בקוד המתאים, ננתח את המבנה של הפקודה, ויהיה לנו את הקוד שאנחנו צריכים להריץ. אבל במערכות כמו UNIX המימוש הוא קצת אחר: יש לנו קבצים, כל קובץ הוא תוכנית, שמממשת פקודה מסוימת, למשל rm, זאת פקודה שאמורה למחוק לנו קובץ מתוך המערכת, אנחנו רוצים למחוק את file.txt,הדרך שלנו להריץ את הפקודה הזאת היא ללכת לחפש את קובץ ההרצה המתאים, יהיה לנו קובץ שנקרא rm שנצטרך למצוא במחיצה שאנחנו נמצאים בדיסק וניקח את התוכנית ששמורה בו ונייצר ממנה process, והprocess הזה יקבל כקלט את file.txt, הוא יצטרך לגשת למערכת ניהול הקבצים, למצוא את file.txt ולמחוק אותו משם. אחרי מחיקת קובץ מ.ה צריכה לאסוף בחזרה את המשאבים שבהם השתמש הprocess, ז"א הגענו לסוף התוכנית rm, כעת תהיה איזו system call exit, וזה אומר למ.ה שסיימנו להריץ את אותו process ואפשר להוריד את הprocess. (עד כאן - ההסבר של דודי) תשובה רישמית: search for a file called rm load file into memory execute it with the paramter file.txt במהלך ההפעלה תהיה גישה למערכת הקבצים וטיפול באמצעות הsystem call הרלוונטי, כמו open ו close. בסוף ההרצה ביצוע system call של exit ואיסוף המשאבים.

מה ההבדל העיקרי בין process ל program?

הסבר של דודי: כמובן שיש המון הבדלים, העיקרי: ל-process יש state בניגוד לprogram שהיא ישות פסיבית ששמורה על הדיסק, ניתן להעתיק אותה, למחוק אותה, ולעשות עליה כל דבר שאפשר לעשות למשהו שהוא פסיבי. ל-process אנחנו לא יכולים להעביר אותו ממחשב למחשב, הוא כרגע רץ במערכת הקיימת- זו שאני עובד איתה, הוא משנה את מצבו כל הזמן, בכל רגע נתון שנסתכל על תמונת הזיכרון שלו הוא יראה אחרת. תשובה רשמית: ה-process הוא למעשה תוכנית בהרצה (ישות אקטיבית לעומת ישות פסיבית) הprogram היא רק הקוד והנתונים, ואילו ה process משנה את הstate שלו במהלך הריצה.

במערכת 3 תהליכים (proc1,proc2,proc3) אשר מתחרים על 6 משאבים - A,B,C,D,E,F כמות המופעים מכל משאב היא 1. יש פה קטע קוד דיי ארוך אז תצפה ב 2:09:00 האם 3 התהליכים עלולים להכנס לדדלוק?

הקוד דיי פשוט, ניתן לראות שכל תהליך נועל 3 משאבים בהתחלה ואז משחרר אותם. המשאבים שעושים להם נעילה בהתחלה הם שונים מתהליך לתהליך. בשביל שיהיה לנו דדלוק מה שצריך זה שהסדר של הלוקים שהם עושים הוא יהיה כזה ששלושתם יגיעו לנק' מסוימת בקוד שלהם שהם נועלים לפחות משאב אחד וממתינים לפחות למשאב אחד שאחרים נועלים. הדדלוק היה כזה: תהליך 3 יהיה תקוע בלוק C, תהליך 2 יהיה תקוע בלוק D, תהליך 1 יהיה תקוע בלוק B. למה הם תקועים? כי תהליך 3 מחכה לC ו-C כבר עשו לו לוק בתהליך 2, תהליך 2 מחכה לD ו-D כבר עשו לו לוק בתהליך 1 תהליך 1 מחכה לB ו-B כבר עשו לו לוק בתהליך 3 כדאי לראות את הפתרון + ההמחזה שב2:12:10

הרצאת שאלות חזרות שנייה, דגש על ניהול זכרון וקבצים

הרצאת שאלות חזרות שנייה, דגש על ניהול זכרון וקבצים

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

התשובה היא כמובן "תלוי". - אם יש הרבה page faults אז זה כנראה עניין של זכרון - אם לא אז כנראה שהתהליכים נמצאים בcpu-bound ואז התשובה זה המעבד. -אם המחשב במצב יציב (כלומר יש מיקס טוב בין cpu-bound לio-bound ואין הרבה Page faults) אז כדאי להשקיע בשניהם.

כיצד יוקצה זכרון לתהליכים בגודל 290K, 420K 110K ו-350K המגיעים בסדר זה? הנח שמפת הזכרון ההתחלתית נראית כך : (דקה 1:17:50) (הלבנים זה החורים שיש לנו)

יש כמה סוגים של הקצאות : bestfit, firstfit, worstfit. בfirst fit: (מכניסים לחור הראשון שפנוי) יגיע ה290, איפה נשים אותו ? ב500, ישאר 210. יגיע ה420 ל600, נשאר 180. יגיע ה110 ילך לאיפה שה210. יגיע ה350 ואין לו מקום ! (הכנסנו 3 תהליכים בלבד) בbestfit: (תחושת הבטן היא שבא זה יצליח אבל זה לא מחייב) (מכניסים לחור הכי קטן שמסוגל להכיל את כל התהליך) יגיע ה290 נכניס אותו ב300, ישאיר חור בגודל של 10. יגיע 420 יכנס ב500, ישאר 80. יגיע ה110 נכניס אותו ב200, ישאר 90. יגיע ה350 נכניס אותו ב600, ישאר 150. (הכנסנו את כל 4 התהליכים) בworstfit: (מכניסים לחור הכי גדול שיש) יגיע ה290, יכנס ל600, ישאר 310. יגיע ה420 יכנס ל500 ישאר 80. ה110 יכנס ל310 שנשאר מה600, ישאר 200. ה350 לא יכנס, לא יהיה לו מקום (הכנסו 3 תהליכים בלבד).

יש פה שאלה ארוכה מוות ב 29:50. אני לא אכתוב את השאלה, רק bullets. -יש 6 חברים ומחסן אספקה - כל חבר יכול להחליט על הכנת יין בכל נק' זמן - כדי להכין את היין צריך לערבב אותו -תהליך התסיסה לוקח 4 שבועות - להשתמש בסך הכל ב2 קנקנים במעודון יש : 2 תחנות ערבוב, 6 קנקנקים גדולים, 7 מתסיסי שמרים, 15 קנקני מיץ פירות ו20 חבילות שמרים שואלים אם יכול להיווצר דדלוק בתוכנית שנתונה פה. שואלים גם על race condition, האם יש פה.

יש לנו משאבים, מה שמעניין אותנו זה הדברים שקשורים לדדלוק. מה למשל יכול להיות פה hold and wait שלא יהיה mutal exclusion. כל אחד מהחברים יהיה process. הקטע של הקוד זה שהרי יש לנו 6 אנשים ו6 קנקנים ויש קטע שצריך לערבב עם קנקן נוסף, אז הטריק פה זה שמקצים 5 קנקנים ל6 אנשים ועוד קנקן שהוא "רק לערבוב", ואז אך ורק כשהקנקן לערבוב פנוי אפשר לערבב, ככה מונעים מצב שבו 6 האנשים משתמשים בקנקנים ואז הם יחכו עד אינסוף לקנקן שישמש אותם לערבוב. יש לנו פה גם race condition, כי יש את הבדיקה של האם יש מיץ ושמרים- ואז הפחתה מהכמות, אבל גם אחרים בדקו את זה והפחיתו אומנם את העדכון עצמו לא נעשה בו זמנית כולנו כי יש שם Mutex, אבל כולנו נעשה את העדכון וכמות השמרים והמיץ תרד מתחת לאפס. (זה לא באמת race condtion אלא יותר כמו שימוש לא נכון בmutex ) אומנם העדכון לא קורה בו זמנית של הערכים אבל היה צריך לשים את הmutex עוד לפני שבכלל בדק האם יש מיץ. כי יכול להיות שאפשר לי לעבור את התנאי הזה כשלא מגיע לי לעבור אותו (יתן לי לעבור את התנאי כי כאילו יש מיץ אבל תכלס אין)

3:16:00, חייב לצפות כי יש גם קוד ידוע שבבעיית הפילוסופים הסועדים היו 16 פילוסופים ו n=16 מקלות אכילה. בניגוד למתואר בבעיה המקורית, כעת מונחים המקלות במרכז השולחן, ובעת שרוצה פילוסוף לאכול הוא מרים שני מקלות ממרכז השולחן (אין חשיבות איזה מהם). לאחר שסיים לאכול הוא מניחם בחזרה במרכז השולחן, וחוזר למחשבותיו, וכך היה התהליך חוזר על עצמו עד אינסוף. להלן מספר פתרונות לבעיה, צריך לכתוב עבור כל פתרון: א- האם יכול להיווצר דדלוק? ב- האם יכול להיוותר הרעבה? ג- מהו המקרה הגרוע ביותר, שבו מספר הפילוסופים שיכולים לאכול בן זמנית הינו הנמוך ביותר? ד- במידה ומימוש הsemaphore הוא כזה שאם ערכו שלילי נכנס התהליך למחסנית, וההוצאה מהמחסנית מתבצעת בשיטת FIFO, האם ישתנו התשובות לעיל?

כל ההבדל מהשאלה המקורית זה מ5 סעודים ל16 ושכעת המקלות במרכז השולחן ולא ליד כל סועד. הקוד הראשון ב3:20:00: א. יכול להיווצר דדלוק כי כל פילוסוף היה מריץ את הchopstick.down הראשון אצלו בקוד ואז כל אחד מהם היה מחזיק מקל אחד ועכשיו יש 16 שמחזיקים מקלות והם לא יכולים לבצע עוד chopstick.down (אין עוד מקלות) ב. עלול להיות הרעבה. במצב בו יש פילוסוף איטי ו15 פילוסופים מהירים שמספיקים לעשות chopstick.down chopstick.down ואז הם יכולים לאכול בכיף ולהחזיר את המקלות ואז אם הם מהירים הם יכול לעשות את זה שוב ושוב ככה שיצא מצב שהם יאכלו שוב ושוב אבל יהיה איזה פילוסוף איטי שלא יצליח לאכול כלל. ג. המקרה הגרוע ביותר הוא דדלוק שבו אף פילוסוף לא יכול לאכול. כלומר 0. ד. לא היה starvation במצב כזה, כי אם שמו אותי עכשיו בתור לא יהיה מצב שהפילוסוף האיטי יפספס את ההזדמנות שלו לאכול. יהיה מי שינהל את זה. כל יתר התשובות לא משתנות.

להלן מימוש קוד של mutual exclusion. דקה 2:37:40 המשתנה s הוא משתנה גלובאלי המשמש את כל התהליכים, ומועבר by refernce. ואילו v הוא לוקאלי בתהליך. א.האם הקוד המוצע מבטיח mutual exclusion? אם לא, מהו התיקון המתבקש? אם כן נמק מדוע. ב. האם הקוד יכול לשמש יותר משני תהליכים או שהוא מוגבל לשניים בלבד? נמק ג.מה המצב (state) של תהליך הממתין להכנס לcritical section ?

כן, כי כל תהליך מקבל id שונה (והם לפי סדר עולה). שתהליך אחד נכנס לקוד הקריטי, אף תהליך אחר לא יכול להמשיך מעבר ללולאה. רק כאשר התהליך שהיה בקטע הקריטי יוצא ממנו ומשנה את turn תהליך הבא נכנס לקטע הקריטי. ב. לא מוגבל. הקוד יכול לשמש יותר משני תהליכים כי הturn ו id עולה כל פעם באחד. ואת הלולאה עובר רק תהליך שהגיע תורו, ואין שום הגבלה במספר התהליכים ג.תהליך הממתין להכנס לקטע קריטי נמצא במצב busy-wait. לכן תהליך יכול להיות במצב של running (כאשר הוא ממש מבצע את הwhile) או במצב של ready (מחכה להכנס ל while)

האם את בעיית הThrashing ניתן לפתור ע"י הוספת זכרון למחשב? לודגמא, האם היינו פותרים לחלוטין את בעיית הthrashing במידה והיינו יכולים לשדרג את כמות הזכרון במחשב לכמות אינסופית ? אם כן, הבא צידוקים לתשובתך. אם לא, הדגם מדוע

כן. אם אני יוכל תמיד להביא עוד ועוד זכרון אז לא משנה מה יהיה הלוקאליטי של התהליכים שרצים, אני יוכל לתת להם מספיק זכרון שיתפוס את כל הלוקאליטי מה שיפתור לי לחלוטין את בעיית הthrashing.

מנה 2 סיבות בגינן האלגוריתם של Banker לא באמת ישים בסביבה אמיתית בה פועלות מערכות הפעלה. נמק והסבר כל סיבה.

למדנו שיש 3 שיטות לטיפול בדדלוקים, מניעה, התאוששות והתעלמות. אלגוריתם banker: אלגוריתם banker עוסק בנושא של דדלוק. מתעסק במניעה של דדלוקים. (בנגיוד להתאוששות והתעלמות) בהתאוששות- אני נותן למערכת להכנס לדדלוק ומוציא אותה ע"י אלגוריתם של זיהוי דדלוק ואלגוריתם התאוששות ממנו- ע"י preemption. אמרנו גם שאלגוריתם banker משמש אותנו כשיש מספר מופעים לכל משאב, כי אם יש לי רק מופע אחד מכל משאב אז כל מה שאני צריך זה רק למצוא מעגלים. כאשר לכל משאב יש יותר ממופיע אחד, גרף הקצאת המשאבים לא יעזור לנו, כי קיום מעגל בו לא בטוח יעיד על דדלוק. השימוש באלגוריתם banker גורר איתו מספר הנחות בסיס: - כל תהליך מצהיר מראש את הכמות הקמסימלית שהוא עלול להצטרך ממשאב מסוים. - כאשר תהליך מבקש משאב, ייתכן והוא יאלץ לחכות כדי להשאיר אותו בsafe state. - כאשר תהליך מקבל את כל המשאבים הדרושים לו הוא חייב להחזיר אותם לאחר זמן סופי. safe state = זה מצב שאם אמשיך ואשמור עליו אז לעולם לא אכנס לדדלוק. האלגוריתם מתבצע ב2 שלבים. בשלב הראשון, נבצע אלגוריתם הנקרא safety Algorithm. אלגו' זה בודק האם המערכת במצב בטוח. בודקים האם במקסימום דרישה של התהליכים נהיה במצב של דדלוק או לא.(כלומר האם במקרה הגרוע שבו הם מבקשים את הדרישה המירבית שלהם) בשלב השני- יתבצע אלגוריתם שבודק האם המערכת תהיה בטוחה גם לאחר הקצאת המשאבים עבור תהליך pi. הדרך להחליט האם להקצות או לא הייתה דרך זה שאמרנו האם הההקצאה שאעשה עכשיו תוציא מsafe state. בשביל לבדוק את זה עשינו "הקצאה ווירטואלית" כאילו אני מקצה את המשאבים, ואם עדיין אהיה בsafe stateאני יכול להקצות את המשאבים אחרת אני אחכה שיתפנו לי עוד משאבים. אז למה Banker לא באמת ישים בסביבה אמיתית בה פועלות מערכות הפעלה? - לתהליכים קשה לבוא ולהגיד בכמה משאבים הם ישתמשו. הם יכולים לתת חסם עליון כלשהו. הבעיה עם החסם העליון שהוא מוריד לי משמעותית את הניצולת של ההתקנים השונים, ז"א אם תהליך בא ואומר חסם עליון גבוה מאוד אני צריך להתחשב בזה וזה מונע מתהליכים אחרים רק בגלל שאולי הוא יצטרך כמות כזאת של משאבים. - האלגוריתם מסתכל על סט נתון של תהליכים, אבל בעולם האמיתי יהיו לי עוד תהליכים. כלומר תהיה בעיה כאשר יגיע עוד תהליך, לא בטוח שיהיה לי משאבים בכלל לעוד תהליך. - ההנחה שכל המשאבים של התהליך ישוחררו בסיום השימוש לא מציאותית *לסיכום, יש פה לא קצת בעיות באלגוריתם הזה של באנקר.

לאיזה מטרה משמשים הcore dump file וה- crash dump file, מתי הם נוצרים ומה שמור בכל אחד מהם?

מדובר בקבצים שאמורים לסייע בdebugging ונוצרים במקרה של תקלה.הcore dump file שומר את תמונת הזיכרון של התהליך בעת התקלה. אם יהיה לי את תמונת הזכרון של התהליף על הדיסק שמורה, אחרי שהתקלה קרתה והתהליך נפל לי, אני אוכל ללכת לתמונת הזכרון ולהסתכל מה היה המצב ולנסות לנתח. crash dump file שומר את תמונת הזכרון של הקרנל בעת תקלה במערכת ההפעלה, ואז אני יכול ללכת ולתחקר.

מה הם היתרונות העיקריים שבשימוש בvirtual machine, הסבר עבורי מפתחים ועבור משתמשים.

למה בכלל יש את ההפרדה (מפתחים / משתמשים) כשדיברנו על עניין היעדים של מערכת הפעלה, אמרנו שאנחנו הרבה פעמים מפרידים בין מה שהיו רוצים מפתחים לבין מה שהיו רוצים משתמשים של מערכת ההפעלה, אז כמובן שתהיה פה איזושהי חפיפה, אבל גם היו דברים שונים. עבור מפתחים: (רישמי) - מאפשר לבדוק את אותה אפליקציה על מספר מערכות הפעלה ללא צורך בחומרה נוספת או העלאה מחדש של המחשב עבור משתמשים: - מאפשר להריץ אפליקציות שונות שפותחו במקור למערכות הפעלה שונות מבלי לבצע restart של המחשב והעלאתו מחדש עם מערכת הפעלה שונה. יתרונות חופפים בין השניים: -מאפשר הפרדה מלאה בין מספר תהליכים רצים (הפרדה מלאה בזכרון וכו') - מונע פגיעה במערכת ההפעלה ה"אמיתית", ובכך מונע התקנה מחדש. - מונע צורך בrestart של המשחב במקרה של קריסה (כל מה שצריך זה להפעיל את הווירטואליזציה מחדש)

בעת הדלקת המחשב או בעת ביצוע reboot, עולה bootstrap program. היכן מאוחסת התוכנית במקור? מה מבצעת התוכנית?

מאוחסנת בROM או בEPROM. מדובר פה על program. תוכנית שאנו מריצים. ROM= זיכרון לקריאה בלבד, אמצעי לאחסון נתונים, דמוי זיכרון מחשב, המכיל נתונים הנכתבים בו פעם אחת, ונקראים ממנו פעמים רבות. שבבים אלה אינם ניתנים לכתיבה חוזרת (בצורה פשוטה), ומכאן השם קריאה-בלבד. בניגוד ל-RAM, תוכן ה-ROM נשמר גם לאחר ניתוק מקור מתח. הגישה ל-ROM פשוטה יותר ומהירה בהרבה מאשר גישה לאמצעי אחסון מגנטיים ואופטיים כגון דיסק קשיח או תקליטור. מה עושה התוכנית: מאתחלת את כל מרכיבי המערכת, מעלה את הkernel של מערכת ההפעלה ומעבירה אליה שליטה. נזכיר שברגע שהשליטה עברה למ.ה , מה שהוא מ.ה זה היא מחכה, מ.ה היא event driven, מונעת ע"י אירועים שקורים ולא עושה שום דבר בעצמה.

האם תהליך יכול לעבור למצב של thrashing שלא כתוצאה משינוי בכמות הframes המוקצים עבורו בRAM? (הנושא הזה בהרצאה 9)

נמחיז את זה: יש תהליך, התהליך עובד עם virutal memory, חלק מהpages שלו בזכרון, חלק לא בזכרון, איזה pages בזכרון? כמות הpages שבזכרון היא ככמות הframes שמוקצים לו. אם אני אתחיל להוריד לו frames, באיזשהו שלב הוא כבר לא יוכל להחזיק את הלוקליטי שלו בזכרון ויעבור למצב של thrashing. אבל בשאלה שואלים האם יהיו עוד מצבים שתהליך יעבור למצב זה שלא בגלל ההסבר שכתבנו עכשיו ? *חשוב להבין מה זה אומר לוקאליטי, לוקאליטי זה מסמן את הסביבה שכרגע צריכים על מנת לסיים את הריצה של תהליך כלומר איזה pages צריכים בכל סביבה, יכול להיות שבסביבה מסויימת צריכים הרבה את הדפים 1,3 ובסביבה אחרת צריכים את הדפים 2,3,5. כל סביבה כזאת משפיעה על כמות הpage faults.שווה להעיף מבט בסיכום של שניר הרצאה 9 עמוד 9) אז עוד טיפה סדר בבלאגן: הworking set זה הpages שכן נשמרים בזכרון, כל עוד יש דף שצריך ואין אותו בworking set זה אומר page fault. כאשר קורה page fault ה working set צריך להעיף את דף כלשהו (ראינו מספר שיטות לבחירה של איזה דף לזרוק) ולשים את הדף הרלוונטי במקומו. הworking set הוא דינמאי ומשתנה בהתאם. thrashing זאת תוצאה קטלנית שבה אין מספיק מספיק מקום בזכרון לכל ה-working set של התהליך לדפים שהוא צריך (בו זמנית), אז המערכת מבקשת דף מסוים ונפרדת מדף אחר וזה יכול להיות לולאה אין סופית של בקשת דף וזריקת דף. אנחנו נרצה כמה שיותר להחזיק בworking set שלנו את הלוקאליטי, כי ככה נקבל שיעור page fault נמוך. אם הלוקליטי משתנה (באופן טבעי במהלך הריצה של התהליך) משמע שיעור הpage fault יעלה כי ייתכן שלא יהיו את הדפים הרלוונטים בזכרון (בworking set). סה"כ תשובה סופית: נכון שטבעי לחשוב שמצב של thrashing יקרה בעקבות מגבלת זכרון, כלומר יהיה איזה שינוי בכמות הframes שמוקצים לתהליך בזכרון ואז באופן סביר יהיה thrashing (אנחנו מתייחסים בכוונה לשינוי בגודל הframes המוקצים בגלל שאם מלכתחילה לא הקצו מספיק מקום אז הייתה פה תקלה אחרת) . אבל ייתכן שהוא יקרה גם בגלל סיטואציה שבה משתנה הלוקאליטי, הסביבה כרגע של הדפים שצריכים משתנה, והיא נעשית גדולה יותר ממה שהיא הייתה, משמע כדי למנוע שיעור page fault גבוה כעת צריך יותר מקום בזכרון (צריך working set יותר גדול בזכרון) והוא עלול למצוא את עצמו במצב של thrashing.

משה הוא ארכיטקט המערכת בחברת UltimateSystemes שמפפתחת מערכות הפעלה חדשה למערכות מרובות מעבדים. על מנת שלא להתפס לקיטריון שיבוץ ספציפי ובהשראת תורת המשחקים, מחליט משה שכך תהליך הממתין בready queue יקבל עם כניסתו למערכת אסימון ווירטואלי ובכל 10 מילישניות שהוא ממתין בready queue אסימון נוסף (ללא הגבלה על כמות האסימונים). תהליכים ישובצו על המעבדים השונים לפרק זמן K, ובע שמתפנה אחד המעבדים מבקש ה scheduler מכל אחד מהתהליכים להודיע (באמצעות מנגון shared memory או message passing) כמה אסימונים הוא מוכן "לשלם" תמורת שיבוץ כעת. קביעת כמות האסימונים אשר יציע תהליך תיעשה באמצעות קוד שיהיה חלק מהתוכנית שיצרה אותו, אשר התוכניתן יכול לעשות לו Override. אסימונים שלא נוצלו עד השיבוץ יישמרו אצל התהליך וניתן יהיה לעשות בהם שימוש בפעם הבאה שייכנס לready queue. מהי הבעיה המרכזית של המנכנון המוצע בהקשר לעקרונות מערכות הפעלה שלמדת בקורס? פישוט השאלה:מהי הבעיה המרכזית של המנכנון המוצע בהקשר לעקרונות שלמדנו לגבי הshort term schduler.

ננסה להוציא מהשאלה את הטפל. מה הכוונה קריטריון שיבוץ ספציפי- כנראה השאלה תעסוק בנושא הscheduling, למשל First come first search, shortest job first, priority scheduling, round robin. משה ממציא שיטה משלו, זה כמו מכירה פומבית כזה שהתהליכים מתחרים בינהם על מי מוכן לשלם יותר כדי לקבל זמן מעבד (לקבל פרק זמן של K). *רעיון שמוצע בכיתה- שיהיה starvation, אבל זה שגוי, כי אומנם יכול להיות תהליך שיחכה ויחכה ויחכה לקבל זמן מעבד, אבל ככל שהוא מחכה יותר הוא נהיה "עשיר" יותר ואז בשלב כלשהו הוא יהיה מספיק עשיר בשביל לקבל זמן מעבד. ולכן זה לא נכון. process חדש שיגיע לאט לאט יצבור אסימונים ויצליח להשתלב. תשובה נכונה- תקורה גבוהה, יש פה הרבה מאוד זמן שיקח להגיע להחלטה מי ישובץ. וזה שלא קורה בו כלום שימושי בעצם, כלומר אין אף תהליך שרץ בנתיים ומתקדם, זה הכי בזבוז של זמן. כל הזמן אמרנו שהמגנון של הshort term schduler הוא צריך להיות פשוט ומהיר, כי הוא overhead הוא לא באמת תורם להרצה של איזושהי תוכנית, הוא תשלום שאני משלם שרץ על גבי המעבד, בשביל הסדר והארגון במערכת שלי. לכן גם למדנו שיטות יחסית פשוטות ("הראשון שמגיע", "קח את זה הזמן עבודה שלו הכי קצר") פה קיבלנו אחלה מנגון, מיישם שיטה של תורת המשחקים, ניראה טוב, אבל- מבקשים מאיתנו שכל פעם שהschduler צריך לפעול הוא צריך להעלות את כל התהליכים שנמצאים בready queue למעבד בשביל שיריצו את הפונקציה שקובעת כמה הם מוכנים לשלם על ההרצה שלהם עכשיו (המכירה הפומבית הזאת היא קוד), יבחר את ההכי גבוה, לא נשכח גם שכל 10 מילישניות נוסף לכל תהליך שבread queue אסימון נוסף, זה overhead מטורף ! זה משהו שלא היינו רוצים בשום סיטואציה שיקרה, זה יוסיף לזמן מעבד עבודה שלא תקדם אותנו בשום דבר, הוא יריץ את הפונקצית מכרז במקום את התהליכים החשובים. *תשובה רישמית למבחן (בלי כל ההסברים היפים): יש כאן המון overhead של תהליך הscheduling ולכן המנגנון לא יעיל.

שאלה על Allocation Methods דיסקים אופטיים מסוג (write once read many- Worm) משמשים חברות לצורך אחסון כמויות גדולות של מידע באופן קבוע ומבלי שניתן לשנותו. בדיסקים אלו כל סקטור ריק יכול להכתב פעם אחת בלבד ולאחריה הוא הופך להיות זמין לקריאה בלבד. כנגזר מכך, לצורך שינוי של בלוק מסויים יש לכתוב אותו כבלוק חדש ולבצע את כל ההתאמות הנדרשות על מנת לשמור על מבנה ארגון הקובץ בדיסק. הינך נדרש לתכנן את מערכת הקבצים של דיסק WORM כך שניצול המקום בדיסק יהיה אופטימלי. האם תבחר להשתמש ב-Conitgouous file allocation, Linked file allocation( הנח שימוש FAT) או Indexed file allocation ? נמק מדוע השיטה שבחרת טובה יותר משי השיטות האחרות עבור דיסק מסודד WORM.

נעבור על השיטות השונות ונראה את היתרונות והחסרונות- *Contigous file allocation- שיטה זו היא בזבזנית עבור WORM. כל שינוי או הגדלה של קובץ עלול לגרור כתיבה מחדש של הקובץ כולו במיקום חדש (כאשר אין מספיק מקום או כאשר נשנה מידע בבלוק קיים) וכך נפסיד גם את המקום הישן של הקובץ וגם את המקום החדש. המקרה היחיד בו לא נצטרך לכתוב את המידע מחדש הוא כאשר אנו רוצים להוסיף בלוק, ויש מקום פנוי ברציפות לאחר הקובץ. *Linked file allocation- בשיטה זו כל שינוי או הוספה גורר כתיבה מחדש של כל הבלוקים עד לבלוק בו ביצענו את השינוי וכן כתיבה מחדש של ה FAT. *indexed file allocation- שיטה זו היא המתאימה ביותר למקרה שלנו כיוון שכל שינוי יאפשר לנו לשנות את הבלוקים המתאימים וכן את בלוק האינדקסים בלבד (ללא צורך לשנות את שאר הבלוקים של השתנו כלל).

ב2:18:13 יש פה שאלה שדודי אומר שעשינו אותה בשיעור ושיש בהקלטה של השיעור ההיברדי.

נקווה למצוא את זה

בערך ב3:04:00 (תראה איך נראית הטבלה) חשב את הcomplition time ואת הwaiting time של כל אחד מהjobs (תהליכים) הבאים כאשר משתמשים באלגורתמי השיבוץ RR , SJF, Multi level feedback queue, השתמש בהנחות להלן: - זמן context switch זניח. - job1 משתמשת בCPU לשנייה וחצי ולאחר מכן דורשת שנייה אחת של I/O, תבנית זו חוזרת על עצמה פעמיים נוספות כלומר סהכ 4.5 שניות של CPU ו3 שניות של I/O. - אם לא הוגדר אחרת, הנח ש job2 מתוזמנת לפני job3. -עבור RR הנח time slice של 2 שניות. אם job מגיע במהלך עיבוד job אחר הוא יועבר לסוף התור. -SJF ממומש כ preemptive. -עבור MLFQ הנח שלוש רמות העובדות עם time slices של 1,2,4 (קודם 1 ואז 2 ואז 4) job1 - length 4.5 arrival time 1 job2- length 10 arrivale time 0 job3- length 2 arriavle time 0

נתחיל ב SJF: נתחיל בjob3 (הרי גם הוא וגם job2 מגיעים בזמן 0, אבל הlength שלו קצר יותר ואנחנו ב SJF). ירוץ שנייה, ואז יגיע job1, עדיין job3 הוא הקצר ביותר (נשאר לו עוד שנייה, וjob1 מבקש שנייה וחצי עד היציאה לI/O) ולא נבצע preemption. אז אחרי 2 שניות Job3 יסיים. יתחיל לרוץ job1, הוא ירוץ שנייה וחצי ואז 2 ירוץ שנייה אחת כי אז יחזור job1. job1 ירוץ עוד שנייה וחצי ואז 2 ירוץ שנייה ואז job1 ירוץ עוד שנייה וחצי, יסיים. ואז job2 שנשאר לו עוד 8 שניות לרוץ ירוץ ויסיים. כעת הcompiltaion time זה קל: לראות כמה זמן לקח. אז job3 סיים ב2 שניות job1 סיים ב9.5 שניות לא לשכוח את הI/O בסוף) אבל לא לשכוח שהוא הגיע בזמן 1 אז סהכ 8.5 שניות. job2 סיים ב16.5 שניות. waiting time: הזמן שהוא סיים פחות הזמן שהוא התחיל פחות הburst. job3= 2-0-2 סהכ: 0 job2= 16.5-0-10 סהכ 6.5 job1 =9.5-1-7.5= 1 נמשיך עם RR: נתחיל עם job2 שירוץ 2 שניות, אחריו job 3 שירוץ 2 שניות אחריו job1 ירוץ 1.5 שנייה אחריו job2 ירוץ 2 שניות אחריו job1 ירוץ 1.5 שניות אחריו job2 ירוץ 2 שניות אחריו job1 ירוץ 1.5 שניות אחריו job2 ירוץ 2 שניות אחריו job2 ירוץ 2 שניות compilation time: job1 יסיים לאחר 12.5שניות (לא לשכוח שיש I/O בסוף) job2 יסיים לאחר 16.5 שניות job3 יסיים לאחר 4 שניות waiting time: job1= 13.5-1-7.5=5 job2= 16.5-0-10=6.5 job3= 4-0-2=2 MLFQ: בזמן אפס מגיעים jobs2,3 לתור הראשון. אז job2 יקבל 1 שניות, ויעבור לתור השני. אבל הוא לא יכול עדיין לרוץ שם, כי קודם התור מעל צריך להיות ריק. Job3 נמצא שם בתור ולכן הוא ירוץ גם עוד שנייה ויעבור לתור השני. בזמן הזה כבר אנחנו בזמן 2 וjob1 מחכה גם הוא בתור הראשון. ירוץ גם שנייה אחת וירד לתור השני. בנתיים כל אחד מהם רץ שנייה וכולם בתור השני. כעת job2 רץ 2 שניות ועובר לתור השלישי job3 רץ שנייה אחת ומסיים job1 רץ עוד חצי שנייה ויוצא לI/O. בנתיים שjob1 בI/O ניתן להריץ בתור השלישי את job2 במשך שנייה אחת. כjob1 חוזר הוא חוזר לQ1 (זה מזכיר את השאלה של ההדפסות שהיה לנו ששיפרה ביצועים) אז בQ1 הוא רץ שנייה יורד לQ2 רץ חצי שנייה ויוצא לI/O. בנתיים בQ3 רץ job2 עוד שנייה. ואז job1 חוזר לQ1, רץ שם שנייה ויורד לQ2 רץ שם עוד חצי שנייה ויוצא לI/O. ואז job2 ישאר לבד וירוץ עד שיסיים. complition time: job3 יסיים לאחר 6 שניות job1 יסיים לאחר 11.5 שניות job2 יסיים לאחר 16.5 שניות waiting time: job3= 6-0-2=4 job1= 12.5-1-7.5=4 job2= 16.5-0-10=6.5

בעת שהתכונן לבחינה במ"ה עלה במוחו של טל רעיון לחיסול הpage table במנגנון ניהול הזכרון. לשיטתו עדיין יהיה ניתן להשתמש בframes בגודל קבוע עבור הזכרון הפיזי, אולם כחלופה לpage table עצמו, מציע טל להשתמש באחת משיטות הקצאת הזכרון המשמשות לקבצים. הנח כי זמן גישה לזכרון הוא 1 ננו-שניה. א. חשב את הEAT עבור גישה למקום d (offset) בדף p כאשר עובדים בשיטה של טל באמצעות שימוש ב: -contiguous allocation - Linked allocation (אין FAT) - Indexed Allocation. ב. האם וכיצד היה משתפר ה EAT בLinked במידה והיינו משתמשים בFAT ?

עבור contiguous יש לנו אפשרות גישה אקראית ולכן זה גישה 1. עבור Linked, נאמר שאין FAT ולכן במקרה הגרוע צריך לעבור על כל הדפים, וזה יהיה כמות הדפים |p|. בIndexed נצטרך לגשת לבלוק האינדקסים והוא יכוון אותנו אל הדף המתאים, ולכן הזמן גישה יהיה 2, (אלא אם הדף גדול יותר מ1000 ואז אולי נצטרך יותר מעברים) ב. לא היה משתנה כי גם ככה אנחנו נעים על גבי הזכרון, הFAT הרי עושה שימוש בזכרון כדי להגיע במהירות לדף הנכון כאשר משתמשים ב Linked.

מהו העקרון במערכות הפעלה על בסיסו פועל הworking set? הסבר.

עקרון הלוקאליטי. הרעיון הוא שברגע נתון אנחנו מסתובבים כל הזמן באותם אזורים בזכרון. יש לנו הרבה מאוד גישות לאותם אזורים.

הנח שהמערכת מצויה במצב הבא מבחינת הקצאה משאבים: 2:14:10 האם המערכת מצויה בdeadlock? במידה וכן, מהם התהליכים המצויים בדדלוק? יש להראות את כל החישובים.

ראשית כבר מהסתכלות על הטבלה ניתן להבין שלא מדובר פה על אלגו באנקר כי אין פה עמודה של MAX וזה הכרחי לבאנקר. למדנו אלגוריתם של detection. שמכריע האם אני מצוי בדדלוק או לא. לא על בסיס איזשהו מקסימום שהם דורשים אלא על בסיס מה שיש כרגע מבחינת הדרישות ומבחינת הallocation שלהם. ניתן לראות שהמשאבים הזמינים, available הם [2,1,0,0]. במצב הקיים ניתן לענות לבקשתו של C בלבד, שדורש request, [2,1,0,0]. לאחר ש C יסיים, הוא ישחרר את המשאבים שהוא משתמש בהם כרגע שזה [0,1,2,0], כמות המשאבים available תגדל ותהיה תהיה [2,2,2,0] (הוספנו את מה שC השתמש בו למה שכבר היה קיים) במצב זה ניתן להענות לבקש של B, לאחר סיום תהליך B נקבל [4,2,2,1]. כעת ניתן להקצות את המשאבים הנדרשים לA. לסיכום- המערכת לא מצויה במצב של דדלוק.

בבעיית הreader-writers אנו מעוניינים לאפשר גישה בו זמנית למספר תהליכים קוראים, אולם לא ניתן לאפשר לתהליך כותב גישה כל זמן שיש תהליכים המבצעים קריאה. ביצוע הקטע הקריטי של תהליך כותב יחייב mutual exclusion (כלומר ללא תהליכים קוראים או כותבים אחרים שיגשו למשתנה המשותף במקביל) להלן קוד לפתרון הבעיה. דקה 3:32:35

שאלה מציקה

שאלות מבחנים מהרצאה 11

שאלות מבחנים מהרצאה 11

נתונה טבלה של ניהול על בסיס סגמנטים (דקה 41:45) א. תרגם את הכתובת הלוגית לכתובת פיזית עבור הבקשה הבאה: הכתובת הלוגית <4,148>. ב. תרגם את הכתובת הלוגית לכתובת פיזית עבור הבקשה הבאה: הכתובת הלוגית <2,13> ג. במידה והתהליך הנוכחי הוא תהליך טיפוסי במערכת (מבחינת סדרי הגודל של כמות סגמנטים וגודלם) האם כדאי לעבור למימוש MULTICS (סגמנטים על בסיס pages) על בסיס הpages שהוגדרו בשאלה הקודמת (גודל 2048)(כן/לא)?

תשובה: א. הסגמנט 4, offset 148. 1952 זה הbase והlength הוא 96. כלומר יש לנו פה בקשה לתא זכרון לא חוקי הסגמנט הזה יש לו רק עד 96 ולא עד 148. ולכן error (תקרא את ב' כדי לחדד את א') ב. הולכים לטבלה ורואים שסגמנט מספר 2 מתחיל ב90, אנחנו רוצים את תא מספר 13 בסגמנט מספר 2 הlength הוא 100 ככה שאנחנו בסדר, ולכן אם נוסיף ל90 , 13, נקבל 103. ג.הסגמנטים פה בגודל קטן בהרבה מ2048,(ניתן לראות את עמודת הlength( זה אומר שהיינו מקצים לכל סגמנט page אחד בלבד,ואז היינו נותנים לו frame בזכרון, זה ממש overkill על כל אחד מהסגמנטים האלה, היינו מקבלים המון פרגמנטציה פנימית, יותר מהחיצונית שאנו מנסים לפתור באמצעות pages. כשאני בא ומפרק את הסגמנטים לpages, זה אומר שבמקום לשמור אותו בצורה רציפה בזכרון אנחנו מפרקים אותו לדפים, ואז אנחנו שומרים אותו בצורה מדולרית (לא היה פרגמנטיה חיצונית כי יש pages שהמבנה שלהם קבוע והם ישבו בframe שמבנה שלהם קבוע), אבל ברגע שאני עובר לדפים צריך לזכור שלכל דף יש פרגמנטציה פנימית, כלומר אני מקצה זכרון בגודל 2048 אז אם היה לנו סגמנטים מאוד גדולים הם היו תופסים ממש כמה דפים ואז בסוף היה נשאר איזה דף שלא מנוצל שזה בקטנה, או אם הסגמנטים היו ממש כמעט בגודל 2048 אז לא הייתה פרגמנטציה פנימית גדולה. אבל פה זה לא הסיפור, פה הגדלים הרבה יותר קטנים מ2048 וכבר בדף הראשון שנקצה תהיה פרגמנטציה פנימית גדולה וזה יצור חורים יותר גדולים מאשר אם היינו מקצים אותם בצורה רציפה בזכרון (ללא דפים)

מה היתרון בשימוש בLinked Allocation? א. אין External Fragmantation ב.יש Random Access ג. יש Internal Fragmantation ד. יש Thrashing

תשובה: א' סעיפים ג' וד' הם שוב חסרונות. בסעיף ב' זה לא נכון, אין Random Access, כדי להגיע לתא בזכרון צריך לרוץ על האיברים הקודמים לו.