Os Technion

(2009מערכות הפעלה )אביב © חגית עטיה 1

מערכות הפעלה234123קורס מס'


מבוא.אדמיניסטרציה .מהי מערכת הפעלה .ארגון מערכות הפעלה


אדמיניסטרטריוויה א פרופ' חגית עטיהמרצהליאוניד רסקיןמרצה ומתרגל ראשי

אתר הקורסhttp://webcourse.cs.technion.ac.il/234123

מכיל הסילבוס ושקפיםיפורסמו באתר הקורס מוקדם ככל האפשרשקפי ההרצאות מאורגנים לפי נושאים


מטרות הקורס במערכות עקרונות התכנון והשימושהבנה של

הפעלה.

של מערכות הפעלה.ניתוח ביצועיםיסודות של

:הבנה של מערכת הפעלה אחתLinux.

מערכת הפעלה.יסודות של תכנות

תכנון מערכות תוכנה גדולותעקרונות של.


מבנה הקורס:הרצאות

עקרונות בסיסיים ומערכות הפעלה אחרות”Unix“מעט דוגמאות מ

:תרגוליםLinuxקוד מערכת הפעלה

:תרגילי-ביתתכנות בעזרת קריאֹות מערכת-הפעלה

תכנות בתוך גרעין מערכת ההפעלהוכמובן, גם תרגילים יבשים...


אדמיניסטרטריוויה ב)ספר הקורס )ראשי

Silberschatz and Galvin,Operating Systems Concepts (≥ 5th ed.)Wiley

)ספר הקורס )משניBovet and Cesati,Understanding the Linux Kernel (2nd ed.)O’Reilly


אדמיניסטרטריוויה ג:ציונים סופיים מבוססים על

)35%תרגילי בית )רטובים + יבשים65%בחינה סופית %5±ייתכן שינוי.

תקףציון התרגילים.

כל תנאי-הקדם יאכפו, ללא הנחותבפרט, קורסים של פקולטות אחרות לא יוכרו כקדם


מהי מערכת הפעלה? שכבת תוכנה לניהול והסתרת פרטים של חומרת

המחשב.

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

חזק מאוד...("Computer Science is the art of abstraction"

מנהלת את משאבי המערכת ומשתפת אותם ביןתהליכים, תוכניות, ומשתמשים.


תפקיד מערכת ההפעלה

מערכת הפעלה

אפליקצי1ה

CPU memory

Disk controller

DevicePrinter controller

אפליקצי2ה

אפליקצי3ה

אפליקצי4ה

מאפשרת להריץ אפליקציות.מבטיחה נכונות

גבולות זיכרוןעדיפויותמצב יציב

.מספקת נוחיותהסתרת פרטיםתיאוםקריאות מערכת-הפעלהמערכת קבצים


שיתוף משאביםאפליקציה רוצה את כל המשאבים:

זמן מעבדזיכרוןקבציםאמצעי קלט / פלטשעון

של אשליהמערכת ההפעלה נותנת לכל אפליקציה מערכת שלמה משל עצמו.


התפתחות מערכות הפעלהחומרה יקרה ואיטית, כוח-אדם זול

Batch jobs 24, ניצול החומרהx7: IBM S/360

חומרה יקרה ומהירה, כוח-אדם זולInteractive time-sharing: Unix

חומרה זולה ואיטית, כוח-אדם יקר :מחשב אישי לכל משתמשMS-DOS


הווה ועתיד.חומרה זולה מאוד, כוח חישוב רב

:ריבוי משימותWindows NT, Windows Vista, Linux, Solaris, BSD, Mac OS X

ריבוי מעבדים וריבוי ליבות(multi-core)... ,שיתוף משאבים בסיסי: דיסקים, מדפסות

.רשתות מהירות :הרשת היא המחשבSETI@home, Grid Computing :הרשת היא אמצעי אחסוןSAN, Web storage


העתיד הקרובסגירת מעגל? וירטואליזציה -

ניתוק מערכת ההפעלה מהחומרהמספר "מחשבים מדומים" על-גבי מכונה פיזית אחת :בשילוב רשתות מהירותCloud Computing - מערכת הפעלה ייעודיתSoftware Appliance

מזעור והטמעה ,טלפון סלולרי כמערכת מחשבNetbooks - מחשוב בכל מקוםPervasive/Ubiquituous

Computing


מבנה המחשבהתנהגות מערכת ההפעלה מוכתבת )חלקית( על-ידי

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

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

בריבוי תהליכים


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

שעון חומרהפעולות סנכרון אטומיותפסיקותקריאות מערכת-הפעלהפעולות בקרת קלט / פלטהגנת זיכרון( אופן עבודה מּוגןprotected)פקודות מּוגנות


פקודות מוגנות חלק מפקודות המכונה מותרות רק

למערכת-ההפעלה

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

טיפול בפסיקות(. פקודתhalt.


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

kernel modeuser mode

יש ארבעה מצבים...(IA32)במעבדי

המצב נשמר באמצעותstatus bit .ברגיסטר מוגן-תכניות משתמש רצות בuser mode.-מערכת ההפעלה רצה בkernel mode.

-המעבד מבצע פקודות מוגנות רק בkernel mode.


אז איך משתמש ניגש לדיסק?קריאה לפרוצדורת מערכת-הפעלה

(system call):קריאה לפסיקה

מציב ברגיסטרeax את מספר המבוקש.system callה-

מכין פרמטרים לפי השרות המבוקש מבצע פקודת“int 0x80”

פרמטר מזהה את קריאת המערכתשומרת את מצב התוכנית הקוראת מוודאת את הפרמטרים )למשל, מצביעי

זבל(רוטינת השירות במערכת ההפעלהחזרה לתוכנית הקוראת כאשר מסיימים

User mode

Kernel mode

Explorer: read()

טיפול בפסיקה

read() kernel routine

חזרה


Intel על מעבדי Linuxדוגמא: :אתחול

( טבלת מזהי פסיקהInterrupt Descriptor Table )( לכל אחד מסוגי הפסיקות.handlersעם מטפלים )

128ווקטור =( 0x80-מתאים ל )system calls. 3, לקוד משתמש עדיפות 0לקוד גרעין יש עדיפות.

כניסה בIDT מכילה:128, המתאימה לווקטור ,-מצביע לקטע קוד גרעין המטפל בsystem calls ליזום קריאה לפסיקה זו.3אישורים עבור קוד עם עדיפות

בביצועsystem call:תהליך המשתמש , מציב ברגיסטרeax-את מספר ה system call.המבוקש מכין פרמטרים נוספים לפי השרות המבוקש מבצע פקודת“int 0x80”.)פסיקה יזומה ע"י תוכנה(


הגנה על הזיכרון מערכת ההפעלה צריכה להגן על תוכניות

המשתמשים, זו מפני זו )עם או בלי כוונה רעה(.

מערכת ההפעלה צריכה להגן על עצמה מפני תוכניותהמשתמשים.

?ועל תוכניות המשתמשים מפניה

:שיטה פשוטהbase register, limit register לכל אחת מהתוכניות.

.מוגנים בעצמם

.זיכרון וירטואליProg C

Prog B

Prog A

Base registerLimit register


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

.מאורע

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

-פסיקות וexceptions: )Interruptsנגרמות על-ידי רכיבי חומרה )שעונים, )פסיקות

סיום ק/פ(Exceptions ,פקודה מפורשת( מגיעות מהתוכנהpage fault)


רכיבי מערכת ההפעלה

זאת ועוד...אתחולגיבוי...?דפדפן

תהליכיםזיכרוןקלט / פלטזיכרון משנימערכות קבציםהגנהניהול חשבונות משתמשים( ממשק משתמשshell)


ארגון מערכת ההפעלהתקשורת זולה בין מודולים

קשה להבין קשה לשנות או להוסיף

רכיבים

מה האלטרנטיבה?

בראשית... מונוליתית

תוכניות

משתמש

חומרה

גרעין מערכת ההפעלה


ארגון מערכת ההפעלהאח"כ... גרעין קטן בראשית... מונוליתית

תוכניות

משתמש

חומרה

גרעין מערכת -Microההפעלה

kernel

חומרה

תוכניות

משתמש

System processes

Use

r mode

file system scheduling

networking

הגנה ניהול המעבד

זיכרון וירטואלי


ארגון מערכת ההפעלהאח"כ... גרעין קטן Micro Kernel שכבה דקה :

מספקת שירותי גרעין

אמינות גבוהה יותרקל להרחיב ולשנות ביצועים גרועים )מעבר בין

user-mode לבין kernel-mode)

דוגמאות:Mach, OS X, ~Windows NT

Micro-kernel

חומרה

תוכניות

משתמש

System processes

Use

r mode


networking




ארגון מערכת ההפעלההיום... גרעין מודולרי מודולים דינמיים, שניתן

לטעון ולהסיר אותם מהזיכרון

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

"מונע מהגרעין "להתנפחללא צורך בזיכרון המחשב

קל להרחיב ולשנותביצועים טובים

דוגמאות: Solaris, Mac OS X,

Linux (kernel modules), Windows (Dynamic device

Drivers)

Core kernel

חומרה

תוכניות

משתמש

Use

r m

ode

Device

drivers

New FS

ניתן למצוא ב MICROKERNEL VS MONOLITHIC SYSTEMדיון מאוד מענין על http://www.oreilly.com/catalog/opensources/book/appa.html


networking




תהליכים?מהו תהליך .מבני הנתונים לניהול תהליכים .החלפת הקשר .ניהול תהליכים ע"י מערכת ההפעלה


תהליך :אבסטרקציה

יחידת הביצוע לארגון פעילות המחשביחידת הזימון לביצוע במעבד ע"י מערכת ההפעלה)תוכנית בביצוע )סדרתי = פקודה-אחת-אחר-השנייה

job, task, sequential processנקרא גם


מה מאפיין תהליך? תהליך לעומת תוכנית:

תוכנית היא חלק ממצבהתהליך

תוכנית יכולה לייצר כמהתהליכים

מרחב כתובותקוד התוכניתנתוניםמחסנית זמן-ביצועprogram counterרגיסטרים( מספר תהליךprocess id)


מרחב הכתובות של התהליך

0x00000000

0xFFFFFFFF

address space

code)text segment(

static data)data segment(

heap)dynamic allocated mem(

stack)dynamic allocated mem(

ProgramCounter

StackPointer


מצבי התהליך:כל תהליך נמצא באחד המצבים הבאים

( מוכןready)( רץrunning)( מחכהwaiting)

?מתי מזמנים / מפנים תהליכים

New

Terminated

Ready

Running

Waiting

create

kill I/O, page fault, etc.

I/Odone

schedulepreempt

טווח קצר

/טווח בינוניארוך


מבני הנתונים של תהליך+ שדות!95, מכיל Linuxב בכל זמן, הרבה תהליכים

פעילים במערכת מצבלכל תהליךProcess control block

(PCB) שומר את מצב התהליך כאשר אינו רץ.

נקראProcess Descriptor Linuxב-

נשמר כאשר התהליךמפונה, נטען כאשר התהליך

מתחיל לרוץ.

Process id (PID)

Execution state

Program counter

Stack pointer

Registers

Username

Scheduling priority

Memory limits


PCBמצב המעבד וה-:כאשר תהליך רץ, המצב שלו נמצא במעבד

PC, SPרגיסטרים ,רגיסטרים לקביעת גבולות זיכרון כאשר המעבד מפסיק להריץ תהליך )מעבירו למצב

.PCBהמתנה(, ערכי הרגיסטרים נשמרים ב- כאשר המעבד מחזיר תהליך למצב ריצה, ערכי

.PCBהרגיסטרים נטענים מה-

Context Switch העברת המעבד מתהליך אחד :לשני.


Context switch11תהליך תהליך מערכת ההפעלהמערכת ההפעלה22תהליך תהליך

מתבצע

מתבצע

מוכן

מוכן

מוכן

מתבצע

save state in PCB1

load state from PCB2

save state in PCB2

פסיקה או המתנה

פסיקה או המתנה

load state from PCB1


תורי מצביםמערכת ההפעלה מחזיקה תורים של תהליכים

)תור )או מבנה נתונים מתוחכם יותרready

תורwaiting -למשל ל ,deviceמסוים Wait queue header

cat pcb explorer pcbhead pointertail pointer

Ready queue header

head pointer

tail pointer

explorer pcb emacs pcb ls pcb


ותורי המצביםPCBה- הוא מבנה נתונים בזיכרון מערכת ההפעלה.PCBה-

כאשר התהליך נוצר, מּוקצה עבורוPCB עם ערכי( (.readyהתחלה(, ומשורשר לתור המתאים )בדרך-כלל,

-הPCB.נמצא בתור המתאים למצבו של התהליך -כאשר מצב התהליך משתנה, הPCB שלו מועבר מתור

לתור.

-כאשר התהליך מסתיים, הPCB.שלו משוחרר


יצירת תהליך)יכול ליצור תהליך אחר )הבן( תהליך אחד )האב

שדהppid בביצוע ps -al-ב Linux.

.בדרך-כלל, האב מגדיר או מוריש משאבים ותכונות לבניו-בLinux הבן יורש את שדה ,user.ועוד ,

.האב יכול להמתין לבנו, לסיים, או להמשיך לרוץ במקביל רק תהליך אב יכול להמתין לבניו

CreateProcess(…,prog.exe,…) יש קריאת Windowsב מייצרת תהליך חדש )ללא קשרי אבות/בנים( אשר מתחיל לבצע את

prog.


() UNIX:forkיצירת תהליכים ב-int main(int argc,

char **argv){ int child_pid = fork(); if (child_pid == 0) { printf(“Son of %d is %d\n”, getppid(),getpid()); return 0; } else { printf(“Father of %d is

%d\n”, child_pid,getpid());

return 0; } }

יוצר ומאתחלPCB. מיצר מרחב כתובות חדש, ומאתחל

אותו עם העתק מלא של מרחב הכתובות של האב.

מאתחל משאבי גרעין לפי משאביהאב )למשל, קבצים פתוחים(

באג נפוץ הוא שכיחת סגירת קבציםפתוחים של האב אצל הבן

-שם את הPCBבתור המוכנים עכשיו יש שני תהליכים, אשר נמצאים

באותה נקודה בביצוע אותה תוכנית. שני התהליכים חוזרים מהfork:

0הבן, עם ערך( האב, עם מספר התהליךpid של )

הבן

)(forkנראה בהמשך מימוש יעיל יותר ל


איך מפעילים תוכנית חדשה?int execv(char *prog, char **argv)

.עוצר את ביצוע התוכנית הנוכחית טוען אתprog.לתוך מרחב הכתובות מאתחל את מצב המעבד, וארגומנטים עבור התוכנית

החדשה.-ה( מפנה את המעבדPCB.)מועבר לתור המוכנים

יוצר תהליך חדש!לא


UNIX shellדוגמא: int main(int argc, char **argv){ while (1) { char *cmd = get_next_command(); int child_pid = fork(); if (child_pid == 0) {

execv(cmd); fprintf(stderr, “exec failed!”); } else { wait(child_pid); } }}


זימון תהליכים :מדיניות בסיסיות RR, FCFS, SJFהערכת זמן ריצה ושימוש בעדיפויות זימון מבוסס עדיפויות וריבוי תורים :דוגמאות Unix, Linux, Windows


זימון תהליכים טווח-קצרזימון :

בוחר תהליך מתור המוכנים.CPUומריץ אותו ב-

מופעל לעיתים קרובות)אלפיות-שנייה(.

.חייב להיות מהיר

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

timer למשל, אחרי המתנה למשאב שאינו ניתן לשיתוף בבודדת( או( כמו מדפסת(

Ready

Running

Waiting

I/O, page fault

I/Odone

schedule

טווח קצר

/טווח בינוניארוך

preempt


מדדים להערכת אלגוריתם לזימון תהליכים

עבור זימון טווח-קצר, המדדים העיקריים הם:מינימאלי (= זמן המתנה + זמן ביצוע) זמן שהייה מינימאלית תקורה

(.trade-off אי-אפשר לנצח בשני המדדים )

לפעמים מעוניינים במטרות נוספות:כמה זמן המעבד פעיל של המעבד: ניצולתפוקה( throughput:) כמה תהליכים מסתיימים בפרק

זמן


-First-Come, Firstאלגוריתם Served

התהליך שהגיע ראשון לתור הממתינים ירוץ ראשון חישובייםנותן עדיפות לתהליכים( CPU bound)ממזער ניצול התקנים( לא מספק דרישות שיתוףtime sharing)

non-preemptive ללא הפקעות(: תהליך מקבל( את המעבד עד לסיומו.

מימוש פשוט: תור התהליכים המוכנים הואFIFO.


FCFSדוגמא : של תהליך מרגע הגעתו לתור המוכנים זמן ההמתנה

ועד לתחילת ביצועו תלוי בסדר הגעת התהליכים לטווח הקצר

למשל, אפשרות אחת )התהליכים מגיעים ביחד(:

.17 = 3(/0+24+27)זמן המתנה ממוצע =

.3 = 3(/0+3+6)זמן המתנה ממוצע =

P1 P2 P3324 3

P1P2 P33 3 24


Convoyאפקט השיירהCתהליך עתיר חישובים

I1,…,In תהליכים עתירי I/O

מה קורה? תהליךC.תופס את המעבד

תהליכיIj.מצטברים בתור המוכנים

התקני קלט / פלט מובטלים!

C

I4 I3 I2 I1


Round Robin (RR)תור מוכנים מעגלי המעבד מוקצה לתהליך הראשון בתור מסוימת, מקצבת זמןאם זמן הביצוע של התהליך גדול

q.התהליך מופסק ומועבר לסוף תור המוכנים ,

preemptive ,בדרך-כללq = 10-100msec. מימוש על-ידיtimer שמייצר פסיקה כל q.יחידות-זמן


FCFS לעומת RRזמן סיום:

10תהליכים 100כל תהליך דורש

יחידות-זמן.q=1.

RR FCFS תהליך

991 100 1

992 200 2

1000 1000 10


Shortest Job First (SJF)Shortest Processing Time Firstנקרא גם

מריצים את התהליך עם זמן ביצוע מינימאלי, עד לסיומו..כל התהליכים מגיעים יחד.זמן הביצוע של תהליך ידוע מראשNon-preemptive.

P1 (6) P2 (8) P3 (7) P4 (3) דוגמא:

7= 4(/0+3+9+16 )זמן המתנה ממוצע = מינימאלי לכל סדר זימון אפשרי!

P2P4 P13 86

P37


מדדי יעילות למנגנוני זימוןTi תהליך בטווח הקצר )רץ או מוכן( שלזמן השהייה

ti של תהליך )סכ"ה זמן חישוב(זמן הריצה

של תהליך, תחת מדיניות זמן שהייה ממוצעAזימון

הוא מספר התהליכיםNכאשר

N

kkA T

NH

1

1


להפקיע או לא להפקיע? תהליכים N עבור A עם הפקעה לכל מדיניות זימון למה:

ללא הפקעה כך ש-’Aשמגיעים יחד, קיימת מדיניות הוכחה

A תהליכים לפי מדיניות Nבהינתן זימון של התהליך שמסתים אחרוןPkיהי

לסוף הזימוןPkנצופף את ריצת

לא השתנה Pkזמן השהייה של וזמן השהייה של התהליכים האחרים לא גדל

Pkנחזור על הפעולה עבור יתר התהליכים בלי

AA HH `

Pk Pr Pk PkPr

PkPr Pk PkPr

1

1... ...k NT T T

N


SJFזמן שהייה ממוצע אופטימלי ב

A כשתהליכים מגיעים יחד, לכל מדיניות זימון משפט:הוכחה

היא מדיניות ללא הפקעה.Aלפי הלמה, ניתן להניח ש-

, יש שני תהליכים כך שSJF לא Aאם

Pr מתוזמן מיד לפני Pk אבל ,tk < tr

Pk ו Prנחליף בין

זמן שהייה ממוצע אחרי ההחלפה לא גדל:

ASJF HH

)(1

...)(...)(...1

1 rkiNrkkr ttTN

TtTtTTN

PrPk

Tr Tk

Pr Pk

tr tk


RRזמן שהייה ממוצע תחת כשתהליכים מגיעים יחד, משפט:

את העיכוב שנגרם delayA(i, j) נסמן ב-הוכחה:(. A רץ )במדיניות זימון Pi בגלל שתהליך Pjלתהליך

תמיד

SJFRR HH 2

1 1 1

1 1

( , )

( , ) ( , )

N N N

A k Ak i j

N

i A Ai i j N

N H T delay i j

t delay i j delay j i




תמיד

SJFעבור

SJFRR HH 2

Nji

AA

N

iiA ijdelayjidelaytHN

11

),(),(

Pi Pj

Nji

ji

N

iiSJF tttHN

11

),min(




תמיד

SJFעבור

RRעבור

SJFRR HH 2

Nji

AA

N


11

),(),(

Nji

ji

N

iiSJF tttHN

11

),min(

Pi Pj PiPj Pj Pj Pj Pj Pj

Nji

ji

N

iiRR tttHN

11

),min(2




תמיד

SJFעבור

RRעבור

SJFRR HH 2

Nji

AA

N


11

),(),(

Nji

ji

N

iiSJF tttHN

11

),min(

Nji

ji

N

iiRR tttHN

11

),min(2


Shortest Remaining Time to Completion First (SRTF)

שזמן הביצוע הנותר שלו קצר יותר Piכאשר מגיע תהליך Pkמזמן הביצוע הנותר של התהליך שרץ כרגע

Pkלמעבד, במקום Piמכניסים את

preemptive.ממזער את זמן השהייה הממוצע במערכת

SRTF ,אופטימאלי כאשר תהליכים לא מגיעים יחד .SJFבניגוד ל-


ניבוי זמן הריצה של תהליךאומדן סטטיסטי של הזמן עד לוויתור על המעבד, על-פי

הפעמים הקודמות שהתהליך החזיק במעבדi-הערכת זמן הביצוע לסיבוב ה – i

ti– -זמן הביצוע בפועל בסיבוב הi

לדוגמא,

t0 = 1

½ =

¾ =

iii tα)(τατ 11 10 α

0

0.5

1


זימון לפי עדיפויותלכל תהליך יש עדיפות התחלתיתעדיפות התחלתית גבוהה ניתנת

שסיומם דחוף לתהליכים אינטראקטיבייםלתהליכים

.התהליך עם העדיפות הגבוהה ביותר מקבל את המעבדSJF הוא זימון לפי עדיפויות כאשר העדיפות היא ההופכי של זמן

הביצוע.

של תהליכים עם עדיפות נמוכההרעבה )זמן שהייה ארוך( של תהליכים גורמת להגדלת הזדקנות

(. selfish round-robinהעדיפות שלהם )לדוגמא,


Multilevel Feedback Queues

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

.תהליך מתחיל בתור הגבוה ביותר-בסוף הquantum.יורד לתור נמוך יותר ,לתהליכים עתירי ק/פ לעומת תהליכים אפליה מתקנת

עתירי-חישובתהליך שמשחרר את המעבד לפני סוף הquantum- / בגלל פעולת קלט(

פלט(, חוזר לתור גבוה יותר.

לפי השימוש במעבד )+ עדיפות התחלתית(:עדיפויות דינמיות המתנה ארוכה למעבד - מגדילה את העדיפותריצה ארוכה במעבד – מקטינה את העדיפות


UNIXזימון ב-זימון לפי עדיפויותעדיפות מספרית נמוכה = עדיפות טובה יותרחישוב העדיפות מתבסס על דעיכה אקספוננציאלית

תהליך שהשתמש לא מזמן במעבד מקבל עדיפות גבוהה)גרועה(

)ככל שעובר הזמן, עדיפותו של התהליך קטנה )משתפרת

)תהליכים שיוותרו מרצונם על המעבד )עתירי ק / פיחזרו אליו מהר יותר מתהליכים שעברו הפקעה

)עתירי חישוב(


UNIXחישוב עדיפויות ב-jtעדיפות תהליך בתחילת יחידת הזמן ה- היא:

1 1

2 2

( 1)( )

2

( ) ( ) ( 1)

jj j j

j j j

CPU tP t Base NICE

CPU t U t CPU t

Base priority of Process

User controlable adjustment factor

( ) Average processor utilization by

( ) Processor utilization of in interval

j

j

j

j

Base j

NICE

CPU t j

U t j i


UNIXחישוב עדיפויות ב-jiעדיפות תהליך בתחילת יחידת הזמן ה- היא:

1 1

2 2

( 1)( )

2

( ) ( ) ( 1)

jj j j

j j j

CPU tP t Base NICE

CPU t U t CPU t

40

10

Base

NICE

0

10

20

30

40

50

60


: רעיון בסיסיLinuxזימון ב גרסה נוספת של תורי עדיפויותנדון רק בזימון תהליכים רגילים

( זימון תהליכי זמן-אמתreal time.יתואר בתרגול )-בדומה לunix לכל תהליך יש עדיפות המורכבת ,

מערך בסיס קבוע + בונוס דינמי המתכנת יכול לשנות את ערך הבסיס באמצעות קריאת

)(niceהמערכת הבונוס הדינמי גדל כשתהליך חוזר מהמתנה וקטן )עד

לערך שלילי( כאשר התהליך נמצא הרבה בטווח הקצר תהליך עתיר ק/פ צפוי לקבל עדיפות גבוהה יותר מתהליך

עתיר חישוב בעל אותה עדיפות בסיס


: מנות זמןLinuxזימון ב תהליך מקבלtime slice שאורכו תלוי בעדיפות

הבסיס תהליך עדיף מקבלtime slice.ארוך יותר

תהליך משובץ לתור עדיפות בהתאם לערך הנוכחישל עדיפותו הכוללת

תקופותזמן המעבד מחולק ל( epoch) בכל תקופה, המערכת נותנת לכל התהליכים לרוץ, החל

מאלו הנמצאים בתור העדיפות הגבוה ביותר-כל תהליך רץ עד סיום הtime slice שלו

חדש עבור התקופה הבאהtime sliceואז מקבל


תהליכים :Linuxזימון ב חישוביים ואינטראקטיביים

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

רוצים מעט זמן מעבד, אבל מיידאינטראקטיבייםתהליכים מאפיינים תהליך כאינטראקטיבי אם ממתין הרבה זמן מיוזמתו

)בטווח הבינוני(, כחלק מזמן הריצה הכולל שלו

רוצים לתת לתהליכים אינטראקטיביים כמה זמן שנחוץ מחדשים את הtime sliceלריצה נוספת בתקופה הנוכחית

עוד מידע בתרגול!


Windows NTזימון ב-גם כאן, שימוש בתורים לפי עדיפות

32 תורים (dispatcher ready queues)Real time priority (16-31 )עדיפויותVariable priority (1-15 )עדיפויות שמורה למערכת(0)עדיפות

מדיניותRound Robinעל התור העדיף ביותר שאינו ריק-העדיפות יורדת אם נצרך כל הquantum-העדיפות עולה אם תהליך עובר מwait-ל ready

העדיפות נקבעת על-פי סוג הקלט / פלטק"פ מהמקלדת מקנה עדיפות גבוהה


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


עלות ריבוי תהליכיםתהליכים דורשים משאבי מערכת רבים

מרחב כתובות, גישה לקלט/פלט(file table)...

זימון תהליכים הינו פעולה כבדהcontext switch.לוקח הרבה זמן

תקשורת בין תהליכים עוברתדרך מערכת ההפעלה

מערכת ההפעלה שומרת על הגבולותבין תהליכים שונים


טבעי לי מקבילי...אבל במקרים רבים קל יותר לפתור בעיות באמצעות ריבוי

תהליכים

: מעבד תמלילים1דוגמא ...,מציג פלט, ממתין לקלט מהמשתמש, בודק איות

: שרת קבצים / דואר2דוגמא ממתין לקבל בקשהכאשר מקבל בקשה, חייב להפסיק לחכות ולעבור לטפל בבקשה

פתרון: לבצעforkתהליך הבן מטפל בבקשה שהגיעההאב ממשיך להמתין לבקשות חדשות

...PCBזה פתרון לא-יעיל כי מחייב הקצאת מרחב כתובות,


שומרי משקל:התהליכים שנוצרים לטיפול בבקשות דומים זה לזה

אותו קודאותם משאבים ונתונים

:אבל לא זהיםמטפלים בבקשות שונותנמצאים בשלבים שונים במהלך הטיפול

( אשר lightweight processes תהליכים-דייאט )מרחב כתובות, הרשאות ומשאביםמשתפים


תהליכים-דייאט = חוטים( חוטthread )( הינו יחידת ביצוע )בקרה

בתוך תהליך

במערכות הפעלה קלאסיות"חוט" יחיד בכל תהליך

במערכות הפעלה מודרניותתהליך הוא רק מיכל לחוטים

:לכל חוט מוקצים המשאבים הבאיםprogram counterמחסניתרגיסטרים

Thread Control Block (TCB)נמצאים ב

P1

P3

P2

P1

T1T2

T3


תזכורת: מרחב הכתובות של תהליך

0x00000000

0xFFFFFFFF

address space

code)text segment(




Program Counter

Stack Pointer


מרחב הכתובות של תהליך מרובה-חוטים

0x00000000

0xFFFFFFFF

address space

code)text segment(



Stack for thread 1

PC thread 2

SP thread 1

Stack for thread 2SP thread 2

PC thread 1


ייחודי לתהליך ייחודי לחוטProgram CounterRegistersExecution StackAddress SpaceOpen FilesFile position

חוטים לעומת תהליכים

√

√

√

√

√

√

√

√

X

X

X

√


תהליך מרובה חוטים: תרשים


דוגמה: שרת קבצים:התהליך מחזיר

מחרוזת תווים )במקרהשל קריאה(

סטאטוס)הצלחה/כישלון(

אורך קריאה/כתיבה)בפועל(

תהליך מקבל בקשותעם הפרמטרים הבאים:

:קריאה / כתיבה סוגזיהוי קובץמיקום בקובץאורך חוצץ(buffer)


שרת קבצים: מימוש עם חוט יחיד

פשטותניצול משאבים לקוי, למשל בהמתנה לקלט/פלט

ניתן ליעל ע"י קלט / פלט אסינכרוני וטיפול במספר בקשות בו זמנית

do forever get request; execute request; return results;end;


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

מקבל בקשהמייצר חוט עבודה, ומעביר אליו את הבקשה

חוט עבודהמבצע את הבקשהמחזיר תשובה

תפוקה גבוהה יותרתכנות מורכב יותר

בקשה

חוט עבודה

חוט עבודה

תשובה


יתרונות וחסרונותיצירת חוט יעילה יותר

והקצאת מחסניתthread control blockרק יצירת –החלפת הקשר בין חוטים של אותו תהליך מהירה יותר–

ניצול טוב יותר של משאבים(, חוטים אחרים של אותו תהליך IOחוט אחד נחסם )למשל על –

ממשיכים לרוץמקביליות אמיתית במערכות מרובות מעבדים–

תקשורת נוחה יותר בין חוטים השייכים לאותו תהליךזיכרון משותף–

תכנות מובנה יותרחוסר הגנה בין חוטים באותו תהליך

חוט עלול לדרוס את המחסנית של חוט אחר–גישה לא מתואמת למשתנים גלובליים–


חוטי משתמש וחוטי מערכת חוט משתמש(user threads)

מוגדרים ע"י סביבת התכנותלא דורשים קריאות מערכת ע"י פקודת( זימון בשיתוף פעולהyield)אין החלפת הקשר בגרעין

?מה קורה כאשר חוט נחסם

חוט מערכת(kernel threads)מוכרים למערכת ההפעלה נקראיםlightweight processes

חוטי משתמש מאפשרים לאפליקציה לחקות ריבוי חוטים גם במערכת הפעלה single-threaded.

kernel

process


תמיכת מערכת הפעלה בחוטיםיצירת והריסת חוטים, לדוגמא

thread_create(char *stack)thread_exit(…)thread_join(…)thread_kill(…)

מבני נתונים פנימייםthread control blockProgram counter, stack, registers

מנגנוני סנכרוןלמשל, תיאום גישה לזיכרון משותף


POSIXדוגמא: חוטי ממשק סטנדרטיIEEE 1003.1c ).ליצירת וניהול חוטים )

רקApplication Program Interface.

:דומה מאוד לפעולות המתאימות עבור ניהול תהליכיםpthread_createpthread_exitpthread_join

.כולל מנגנונים רבים לתיאום בין חוטים נתמך בהרבה מערכות“UNIX”

,בפרטNPTL ב Linux ולפניה( PThreads)מימושים שונים

נתמך גם בWindows


Pthreadsהשוואת ביצועים

Linux 2.2.16, עם 700MHz Pentiumבמיקרו שניות, על [Steve Gribble, 2001]

יחס זמן יצירה / סיום:

56 251 fork / exit תהליכים

21 94 pthread_create / pthread_join

חוטי גרעין

— 4.5 pthread_create / pthread_join

חוטי משתמש


Solarisהשוואת ביצועים

. SPARCstation2 (Sun 4/75)במיקרו שניות, על [Solaris Multithreading Guide]

http://docs.sun.com/app/docs/doc/801-6659

יחס זמן יצירה

33 1700 תהליכים

7 350 חוטי גרעין

— 52 חוטי משתמש


Windows NTדוגמא: הינה תהליך. היחידה הבסיסית חוטיםתהליך יכול להכיל כמה – kernel threads. סיביםחוט יכול להכיל כמה (fibers) ,

user threadsשהם בעצם

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

לחוטים


כמה חוטים ליצור בשרת? אם כל חוט צריךtc יחידות זמן ולתהליך מוקצים tp יחידות

זמן )בכל שניה(. כמה חוטים כדאי לתהליך לייצר? -אין טעם לייצר יותר מtp / tc.חוטים

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

חוט עבודה


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

:חוטי העבודה מריצים את הקוד הבא בלולאה אינסופיתקח משימה מהתורבצע את המשימהשלח תשובה ללקוח

)כל חוטי העבודה במקביל(

thread poolingמאגר חוטים

משימה

חוט עבודה

חוט עבודה

תשובה


מאגר חוטים בגודל דינאמי tp וtcאינם ידועים, ואולי אפילו אינם קבועים

ערכו שלtc עשוי לקבוע את tp

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

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

אם יש הרבה חוטים מובטלים, ניתן לבטל חוטים


תיאום בין תהליכים: יסודות

דוגמאות לבעיות תיאום :קטע קריטי, מנעולים הגדרותאלגוריתם קופת-חולים


תיאום:תהליכים משתפים פעולה

גישה למשאבים משותפים, למשל זיכרון משותף )בעיקרחוטים(.

.העברת נתונים מתהליך אחד לשני דרך התקן משותף

:חייבים לתאם את השיתוף.מניחים שביצוע התהליכים משולב באופן שרירותי

למתכנת האפליקציה אין שליטה על זימון התהליכים.

תיאוםשימוש במנגנוני( synchronization.)


דוגמא: בנק הפועלים.מימשנו פונקציה למשיכת כסף מחשבון בנק

int withdraw( account, amount) {

balance = get_balance( account );

balance -= amount;

put_balance( account, balance);

return balance;

}

ושני בעלי החשבון ניגשים 50000$בחשבון יש , 20000$ ו-30000$לכספומטים שונים ומושכים

בו-זמנית.


?בנק הפועלים: אין כסף תהליך נפרד מבצע כל פעולת משיכה )על אותו

מעבד(

.... 0$בחשבון

balance = get_balance(account);

balance -= amount; // 50K-30K

put_balance(account, balance);

return balance; // = 20K




return balance; // = 0


בנק הפועלים: יש כסף! תהליך נפרד מבצע כל פעולת משיכה )על אותו

מעבד(.

מי שמח עכשיו?










עוד דוגמאshared in, out

procedure echo();

read( in, keyboard);

out = in;

write( out , screen);

end echo

שני חוטים מבצעים אותוקוד

החלפת חוטים בכל מקום

race conditionתוצאת הריצה אינה צפויה.


עוד דוגמא: יותר מידי חלב!:יודה :נינט שעה

מסתכלת במקרר 3:00

מסתכל במקרר הולכת לסופר 3:05

הולך לסופר קונה חלב 3:10

קונה חלב חוזרת הביתה 3:15

חוזר הביתה מכניסה חלב למקרר 3:20

מכניס חלב למקרר 3:25


1פיתרון להשאיר פתק לפני שהולכים לסופר

if (no milk) then if (no note) then

leave note buy milk

remove note


1בעיה עם פתרון

פעמיים חלב!



leave note buy milk

remove note

leave note buy milk

remove note


2פיתרון משאירים פתק לפני שבודקים את המקרר:

Thread A: leave note A if (no note B) then if (no milk) then buy milk remove note A

Thread B: leave note B if (no note A) then if (no milk) then buy milk remove note B


2בעיה עם פתרון

אין חלב!

leave note A

leave note B

remove note A

if (no note B) then

if (no note A) thenremove note B


☺ 3פיתרון לא סימטרי

יקנה חלב!A(, race conditionאם שניהם משאירים פתק בו זמנית )לא הוגן

רק לשני תהליכים

Thread A: leave note A while (note B) do nop if (no milk) then buy milk remove note A



לב הבעיה.שני תהליכים נגשים בו-זמנית לאותו משאב, ללא תיאום

.למשל, בגישה למשתנים גלובליים.התוצאה אינה צפויה

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

לכל מבנה נתונים של מערכת הפעלה )וגם להרבהתוכניות משתמש מרובות-חוטים(.

Buffers, queues, lists, hash tables


קטע קריטי קטע קריטיהקוד שניגש למשאב המשותף מכונה

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

קטע קריטי

שארית הקוד


קטע קריטי קטע קריטיהקוד שניגש למשאב המשותף מכונה

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

):atomicityאטומיות )

בביצוע סדרת פקודות ע"י חוט,חוטים אחרים אינם רואים

תוצאות חלקיות

קטע קריטי

(entryכניסה )

(exitיציאה )

שארית הקוד


באלגוריתם לבעית החלב

Thread A: leave note A while (note B) do nop if (no milk) then buy milk remove note A


קטע קריטי

קוד כניסה

קוד יציאה


תכונות רצויותחוטים לא מבצעים בו-זמנית את הקטע מניעה הדדית:

(mutual exclusionהקריטי. ).חוטים מעוניינים מחכים בקטע הכניסה.כאשר החוט הנוכחי יוצא מהקטע הקריטי, יכולים להיכנס



(mutual exclusionהקריטי. )

אם יש חוטים שרוצים לבצע את הקטע התקדמות:, no deadlockהקריטי, חוט כלשהו יצליח להיכנס. )

היעדר קיפאון(.אלא אם חוט אחר נמצא בתוך הקטע הקריטי



(mutual exclusionהקריטי. )

אם יש חוטים שרוצים לבצע את הקטע התקדמות:, no deadlockהקריטי, חוט כלשהו יצליח להיכנס. )

היעדר קיפאון(

אם יש חוט שרוצה לבצע את הקטע הקריטי, הוגנות:, היעדר הרעבה(no starvationלבסוף יצליח. )

רצוי: החוט יכנס לקטע הקריטי תוך מספר צעדים חסום(bounded waiting( ואפילו בסדר הבקשה ,)FIFO.)


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

באמצעות שתי פונקציות:acquire(lock).נחסם בהמתנה עד שמתפנה המנעול – release(lock).משחרר את המנעול –

acquire ו release:מופיעים בזוגות אחריacquire.החוט מחזיק במנעול .)רק חוט אחד מחזיק את המנעול )בכל נקודת זמן.יכול לבצע את הקטע הקריטי


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

int withdraw( account, amount) {acquire ( lock ) ;

balance = get_balance( account ); balance -= amount; put_balance( account, balance);release ( lock ) ;

return balance;}

קטע קריטי


המשך הדוגמא שני תהליכים מבצעים את

פעולת המשיכה

מה קורה כשהאדום מבקשאת המנעול?

מדוע הreturn מחוץ לקטע הקריטי?

?האם זה נכון

acquire(lock);



acquire(lock);


release(lock);




release(lock);

return balance; // = 0



מימוש מנעולים...אם היו לנו מנעולים, היה נפלא:אבל מימוש מנעול מכיל קטע קריטי

קרא מנעולאם מנעול פנוי, אז.כתוב שהמנעול תפוס


דרכים לממש מנעולים:פתרונות תוכנה

.אלגוריתמים( מבוססים על לולאות המתנה(busy wait.:שימוש במנגנוני חומרה

.פקודות מיוחדות שמבטיחות מניעה הדדית.לא תמיד מבטיחות התקדמות.לא מובטחת הוגנות:תמיכה ממערכת ההפעלה

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

.בדרך-כלל, מסתמכים על מגנוני חומרה


אלגוריתם קופת-חולים( ידוע כאלגוריתם המאפיהbakery.)

[Lamport, 1978]

:שימוש במספרים.חוט נכנס לוקח מספר.חוט ממתין שמספרו הקטן ביותר נכנס לקטע הקריטי


1ניסיון חלוקת מספרים:Thread i:

initially number[i]=0

number[i]=max{number[1],…,number[n]}+1;

for all ji do wait until number[j]=0 or (number[j]>number[i])

critical section

number[i]=0 // Exit critical section

חוטi-ו jקוראים את המערך בו זמנית בוחרים את אותו מספר

קיפאון!


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

(.thread idמשתמשים במספר החוט )


בעיה עם האלגוריתם המתוקןThread 1:

number[1]=0

read{number[1],…,number[n]}

Thread 2:

number[2]=0

number[2]=max{number[1],…,number[n]}+1 // =1

wait until number[1]=0 or …

critical section

number[1]=1

wait until number[2]=0

or )number[2],2)>(number[1],1))

critical section

אין מניעה הדדית!


3ניסיון חלוקת מספרים: יבחרו מספריםentryמחכה שכל החוטים ב-

Thread i: initially number[i]=0; choosing[i]=true; number[i]=max{number[1],…,number[n]}+1; choosing[i]=false; for all ji do wait until choosing[j]=false; for all ji do wait until number[j]=0 or

()number[j],j)>(number[i],i)); critical section number[i]=0 // Exit critical section


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

יותר( לפי סדר הגעה.מסורבל

הרבה פעולות, הרבה משתניםפונקציה של מספר החוטים( מבוסס על לולאות המתנה(busy wait

דרכים אחרות לתיאום בין חוטים / תהליכים...עזרה מהחומרה.


תיאום בין תהליכים:שיטות מתקדמות

שימוש בחומרה למימוש מנעולים :מנגנוני מערכת הפעלה לתיאום

סמפורים, משתני תנאי


חסימת פסיקות מימוש מנעולים:lock_acquire(L):

disableInterrupts()

while LFREE do enableInterrupts()

disableInterrupts()

L = BUSY

enableInterrupts()

lock_release(L): L = FREE

חסימת פסיקות מונעתהחלפת חוטים ומבטיחה

פעולה אטומית על המנעול

למה מאפשרים פסיקותבתוך הלולאה?


?חסימת פסיקות:בעיות במערכת עם מעבד יחיד

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

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


תמיכת חומרה במנעוליםL = falseמנעול פנוי – L = trueמנעול תפוס –

lock_acquire(L): while test&set(L) do nop

lock_release(L): L = false

test&set(boolvar) כתובtrue-ל boolvar

והחזר ערך קודם


המתנה בזבזניתspinlock מנעול שיש בו busy waiting:

.)בדוק האם המנעול תפוס )על-ידי גישה למשתנה.אם המנעול תפוס, בדוק שנית...גם בקופת-חולים

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

priority inversion .כאשר לחוט הממתין עדיפות גבוהה :

queue lock מונע :busy wait באמצעות ניהול תור של החוטים המחכים... דורש יותר תמיכה מהחומרה


תמיכת חומרה מתקדמתcompare&swap(mem, R1, R2)

אם בכתובת הזיכרוןmem ערך זהה לרגיסטר R1 כתוב את הערך ,

הצלחה והחזר R2אשר ברגיסטר כישלוןאחרת החזר

.IA32, Sunנתמך בהרבה ארכיטקטורות

load-linked / store conditionalLL(mem) קרא את הערך בכתובת הזיכרון – mem.SC(mem, val)-אם לא היתה כתיבה ל – mem -מאז ה LL(mem)

(כשלון )אחרת הצלחה והחזר mem ל-valהאחרון שלך, כתוב ערך

90נתמך בארכיטקטורות של שנות ה-HP’s Alpha, IBM’s PowerPC, MIPS4000


מנגנוני תיאום גבוהים יותרשל החוטים הממתינים. תורלנהל ☼ :נמצא במנגנוני תיאום עיליים

סמפוריםמשתני תנאי

... מוניטורים


סמפור

שני שדות:ערך שלם / תור של חוטים

תהליכים ממתינים

[Dijkstra, 1968]


פעולות על סמפורwait(semaphore)

-1מקטין את ערך המונה ב ממתינים עד שערכו של

הסמפור אינו שלילי נקרא גםP(), proben

signal(semaphore)-1מגדיל את ערך המונה ב.משחרר את אחד הממתינים נקרא גםV(), verhogen


יותר מידי חלב עם סמפוריםקוד זהה לשני החוטים.

.1בהתחלה , OKToBuyMilkסמפור

wait( OKToBuyMilk);if ( NoMilk ) {

Buy Milk; // critical section } signal( OKToBuyMilk);

ניתן להכנס לקטע הקריטי. 0אם ערך הסמפור <

הסמפור תפוס, וערכו )בערך 0 ≥אם ערך הסמפור מוחלט( הוא מספר הממתינים


סמפור בינארי וסמפור מונה בינאריסמפור

= זה גם הערך המקסימאלי.1ערך התחלתי ;.)מאפשר גישה בלעדית למשאב )בדומה למנעול

מונהסמפור ערך התחלתיN>0. שולט על משאב עםN.עותקים זהים חוט יכול לעבורwait)( בסמפור כל עוד יש עותק פנוי של

המשאב.


דוגמה: בעיית יצרן / צרכןשני חוטים רצים באותו מרחב זיכרון

מיצר אלמנטים לטיפול )למשל, משימות(היצרן מטפל באלמנטים )למשל, מבצע את המשימות(הצרכן

)מעגלי( מכיל את העצמים המיוצרים.חסוםמערך

0n-1

cppp

c

המקום הפנוי הבאהאלמנט המוכן הבא

מספר האלמנטים המוכנים


?פתרון לבעיית יצרן / צרכןglobal variableint c = 0;

Producer: repeat wait until (c < n); buff[pp] = new item; pp = (pp+1) mod n; c = c + 1; until false;

Consumer: repeat wait until (c ≥ 1); consume buff[cp]; cp = (cp+1) mod n; c = c - 1; until false;

???cואם ניגשים בו-זמנית ל-


יצרן / צרכן עם סמפוריםsemaphore freeSpace,

initially nSemaphore availItems,

intiailly 0 Producer: repeat wait( freeSpace); buff[pp] = new item; pp = (pp+1) mod n; signal( availItems); until false;

מספר המקומות הפנויים

מספר האיברים המוכנים

Consumer: repeat wait( availItems); consume buff[cp]; cp = (cp+1) mod n; signal( freeSpace); until false;


קוראים/כותבים דוגמה:כותבים וחוטים קוראיםחוטים

.מספר חוטים יכולים לקרוא בו-זמנית כאשר חוט כותב, אסור שחוטים אחרים יכתבו ו/או

יקראו.

טבלת גישהReader Writer

Reader

Writer


קוראים / כותבים עם סמפוריםint r = 0;semaphore sRead,

initially 1semaphore sWrite,

initially 1

Writer: wait(sWrite) [Write] signal(sWrite)

מונה מספר הקוראיםמגן על מונה מספר הקוראים

מניעה הדדית בין קוראים לבין כותבים

)ובין כותבים לעצמם(Reader: wait(sRead) r:=r+1 if r=1 then

wait(sWrite) signal( sRead) [Read] wait( sRead) r:=r-1 if r=0 then

signal(sWrite) signal( sRead)


?מימוש (תיאורטי) של סמפוריםstruct semaphore_t {

int value; queue waitQ;

}

void wait(semaphore_t *s){s->value--;if (s->value < 0){

enQ(self, &s->waitQ);

block }}

void signal(semaphore_t *s){s->value++;if (s->value <= 0){

P = deQ( &s->waitQ);wakeup(P) }

}


תיקון מימוש של סמפורים:struct semaphore_t {

int value; queue waitQ;lock_t l;

}void wait(semaphore_t *s){

lock(&s->l) ;s->value--;if (s->value < 0){

enQ(self, &s->waitQ);

unlock(&s->l) ;block }

else unlock(&s->l) ;}

void signal(semaphore_t *s){lock(&s->l) ;s->value++;if (s->value <= 0){

P = deQ( &s->waitQ);

wakeup(P) } unlock(&s->l) ;}


? busy-waitingהיה .עדיין יש נעילה: על הגישה לתור השייך לסמפור עדיין ישbusy waiting...

...אבל הקטע הקריטי קצר:.רק לשים / להוריד אלמנט מתור אפשר לתכנת כך שתהיה עבודה בו-זמנית בשני הקצוות

של תור לא-ריק.

ההשלכות של busy-waiting.מוקטנות


חסרונות של סמפורים:לא מפרידים

.נעילה.המתנה.ניהול משאבים

...רעיון מודרני יותר: נקודות מפגש במשתני תנאי


פעולות על משתני תנאיwait(cond,&lock):

.)שחרר את המנעול )חייב להחזיק בו המתן לפעולתsignal..)המתן למנעול )כשחוזר מחזיק במנעול

signal(cond): הממתינים ל אחדהער את cond.אשר עובר להמתין למנעול ,.הולך לאיבוד אם אין ממתינים

broadcast(cond):.הער את כל התהליכים הממתינים.עוברים להמתין למנעול.הולך לאיבוד אם אין ממתינים


הערות משתני תנאי: כאשר תהליך מקבלsignal הוא אינו מקבל את

המנעול באופן אוטומטי, ועדיין צריך לחכות להשגתוmesa-style.

.משתני תנאי הולכים נפלא עם מנעוליםwait(cond,&lock) קודם משחררת את המנעול lock.

,בניגוד לסמפוריםsignal.לא זוכר היסטוריה signal(cond) הולך לאיבוד אם אין ממתינים על cond.


דוגמא – מימוש תורlock QLock ;condition notEmpty;

Enqueue (item):lock_acquire( QLock)put item on queuesignal(notEmpty) lock_release( QLock)

Dequeue (item):lock_acquire( QLock)while queue empty wait(notEmpty, &QLock)remove item from queuelock_release( QLock)

.ממתינים כאשר התור ריק

נעילה להגן על הגישהלנתונים.

.קטע קריטי קצר

משתנה תנאי מאפשרלחכות עד שיתווסף איבר

-busyלתור, מבלי לבצע wait.

למה צריךwhile?


יצרן / צרכן עם משתני תנאיcondition not_full,

not_empty;

lock bLock;

producer:

lock_acquire(bLock);

while (buffer is full)

wait(not_full,&bLock);

add item to buffer ;

signal(not_empty);

lock_release(bLock);

consumer:

lock_acquire(bLock);

while (buffer is empty)

wait(not_empty,&bLock);

get item from buffer

signal(not_full);

lock_release(bLock);


מוניטורמשתני תנאי + מנעול ההקשר המקורי של משתני תנאי[C.A.R. Hoare,

1974]

במובן של שפת-תכנות( אובייקטobject-oriented) ,הכולל פרוצדורת אתחול וגישה.

)הגישה לאובייקט מקנה שליטה במנעול )באופן לא-מפורש שליחתsignal משחררת את המנעול ומעבירה את השליטה

.signalבו למקבל ה

(.Javaנתמך בכמה שפות-תכנות מודרניות )ובראשן,


POSIXמנגנוני תיאום ב אובייקטים לתיאום

.נמצאים בזיכרון המשותף.נגישים לחוטים של תהליכים שונים

mutex locks (pthread_mutex_XXX) :יצירה, השמדהinit, destroylock, unlock, trylock.

condition variables (pthread_cond_XXX) :יצירה, השמדהinit, destroywait, signal, broadcast.


Windows NTמנגנוני תיאום ב-כל רכיב במערכת ההפעלה הוא אובייקט תיאום

ניתן להמתין ו/או לשחרר

אובייקטים מיוחדיםmutexמנעול הוגן –event-משתנה תנאי )עם אפשרות ל – broadcast כדי

להעיר את כל הממתינים(semaphoreסמפור מונה, לא הוגן – critical section – light-weight mutex המיועד

לחוטים באותו תהליך


טיפול בקיפאוןבעיית הקיפאון הימנעות מקיפאון זיהוי קיפאון באמצעות מציאת מעגלים אלגוריתם הבנקאי להתחמקות

מקיפאון


דוגמא: הפילוסופים הסועדים-כל פילוסוף מעביר את חייו ב

חשיבה(thinking) ניסיון להשיג מזלגות(hungry) אוכל(eating)


עם סמפורים פילוסופים סועדים:ריצה פשוטה? פיתרון פשוט

לכל מזלגfork[i]סמפור

wait(fork[i])

wait(fork[i+1])

eat

signal(fork[i])

signal(fork[i+1])

בביצוע מסונכרן כל פילוסוף משתלט כל המזלג שמימינו ואז ממתין

קיפאוןלמזלג שמשמאלו

5

2

1

3

4

1

2

34

5


גרף בקשות-הקצאותגרף מכוון )דו-צדדי( המתאר את מצב המערכת בזמן

כלשהו עיגול לכל תהליך מלבן עםn נקודות למשאב עם nעותקים

קשת מתהליך למשאבהתהליך ממתין למשאב

קשת מעותק של משאב לתהליךעותק של המשאב הוקצה לתהליך


גרף בקשות-הקצאות: דוגמאP1 מחזיק עותק של R2-ומחכה ל R1P2 מחזיק עותקים של R1-ו R2-ומחכה ל R3P3 מחזיק עותק של R3

P1 P2 P3

R1R2

R3


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

P1 P2 P3

R1 R2 R3


גרף לבעיית הפילוסופים הסועדים

P5

P4 P1

P3 P2


קיפאוןקבוצת תהליכים / חוטים שבה כל אחד ממתין למשאב

המוחזק על-ידי מישהו אחר בקבוצה.

מתקיימים התנאים הבאים:

יש מניעה הדדית1. משאבים שרק תהליך אחד יכול לעשות שימוש בהם

בו-זמניתכמה עותקים של אותו משאב נחשבים למשאבים נפרדים

משאבים שאין צורך במניעה הדדית עבורם אינם יכולים(read only fileלגרום לקפאון )למשל,





יש מניעה הדדית1.

החזק והמתן2. תהליך מחזיק משאב ומחכה למשאב אחר שבשימוש אצל

תהליך אחר






החזק והמתן2.

לא ניתן להפקיע משאבים3.






החזק והמתן2.

לא ניתן להפקיע משאבים3.

המתנה מעגלית... 4. תהליכיםP0,P1,…,Pn-1

Pi מחכה למשאב המוחזק ע"י P(i+1) mod n


דרכי התמודדות עם הקיפאון( מניעהpreventionעל-ידי מדיניות שתימנע קיפאון ,)

מניעת המתנה מעגליתלחכות לכל המשאבים ביחד

פקודתWaitForMultipleObjects-ב Windows NT.מקצה את כל המשאבים בבת-אחת, אם כולם פנויים

( גילוי קפאוןdetection)( היחלצות מקפאוןrecovery)( התחמקות מקפאוןaviodance)

שימוש בידע מוקדם על צרכיו של כל תהליך)רוב מערכות ההפעלה לא דואגות למנוע קיפאון )התעלמות

.פעולה כבדה. האחריות נשארת אצל המתכנת.הריגת תהליך מאפשרת להיחלץ מקיפאון

.אך עלולה להשאיר את המערכת במצב לא תקין


מניעת המתנה מעגליתP0,P1,…,Pn-1תהליכים

Pi מחכה למשאב המוחזק ע"י P(i+1) mod n

נקבע סדר מלא בין המשאביםF(tape)=1, F(printer)=2, F(scanner)=3 ,…

תהליכים יבקשו משאבים רק בסדר עולה-תהליך שמחזיק את הprinter-לא יוכל לבקש את ה tape

או... תהליך שמבקש משאב מסדר נמוך חייב לשחרר קודם משאבים מסדר גבוה


מניעת המתנה מעגליתבבעיית הפילוסופים הסועדים

בקשת מזלגות בסדר עולה...

if ( i = 5) then wait(fork[1])

wait(fork[5])

else

wait(fork[i])

wait(fork[i+1])

eat

signal(fork[i+1])

signal(fork[i])

5

2

1

3

4

1

2

34

5


גילוי קיפאון עם עותק יחידקיפאון קורה כשיש מעגל מכוון בגרף בקשות-הקצאות

נובע מתנאי "החזק והמתן"

ו-"המתנה מעגלית"

גילוי קיפאון על-ידי זיהוי מעגלאלגוריתם ידוע למציאת מעגל בגרף מכוון, המבוסס על מיון טופולוגי סיבוכיותO(m) כאשר ,mמספר הקשתות

P1

P2P3

P4


מספר עותקים מכל משאבלא חייב להיות קיפאון גם אם יש מעגל מכוון בגרף

בקשות-הקצאות

ז"א, יכול להיות מעגל בלי שיהיה קיפאון.

גם עבור מערכת עם כמה עותקים

מכל משאב קיים אלג' לגילוי קיפאון

אבל לא נלמד אותו

P1 P2 P3

R1R2


Recoveryהיחלצות מקיפאון

.ביטול כל התהליכים המצויים במצב קיפאון.ביטול תהליכים אחד-אחד עד להיחלצות.הפקעת משאבים

מציאת קבוצה אופטימאלית )של תהליכים או משאבים( לביטול היא בעיה קשה מאוד.


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

תהליכים מצהירים על כוונתם לבקש משאביםאסור לתהליך לבקש משאב שלא הצהיר עליו

אם קיימת סדרת הקצאות לכל המשאבים שהוצהרו,בטוחמצב הוא

מבלי להיכנס לקיפאון.

אם היענות לבקשה עלולה להכניס את המערכת למצב לאבטוח,

אז הבקשה נידחת.

אלגוריתם שמרניהנחות מחמירות לגבי דרישות התהליכים


התחמקות מקיפאון: דוגמאP1-ו P2מצהירים על כוונה לבקש את המדפסת והדיסק

P1מבקש את המדפסת הבקשה נענית

P2מבקש את הדיסק ...הבקשה נדחית אם בהמשךP2 -יבקש את המדפסת ו P1את הדיסק, אזי יהיה קיפאון

בבעית הפילוסופים הסועדים - שמים את המזלגות במרכזהשולחן

:לוקח מזלג, אלא אם כןזה המזלג האחרון ולאחד הממתינים עדיין חסר מזלג אחד

ובאופן כללי, אלגוריתם הבנקאי...


התחמקות: אלגוריתם הבנקאי כאשר תהליך מגיע למערכת, מצהיר כמה עותקים

ירצה )לכל היותר( מכל משאב.

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

את הבקשות של תהליכים שכבר נמצאים במערכת עד למקסימום המוצהר לכל סוג משאב


אלגוריתם הבנקאי: משתניםm ,מספר המשאבים nמספר התהליכים

Available: vector of size m the number of available copies of each resource type

Max: n x m matrixthe maximum demand of each process for each resource type

Allocation: n x m matrix number of currently allocated copies of each resouce type to each process

Need: n x m matrix the remaining copies that might be needed by each processNeed = Max - Allocation

Work and Finish: (temporary) vectors of size m and n


אלגוריתם הבנקאי: פסאודו-קוד

Initialize Work := Available; Finish := [false,…,false];

While (Finish[i] = false & Need[i] ≤ Work), for some

iWork := Work + Allocation[i]; Finish[i] := true;

End whileThe system is safe if and only if

Finish[i] = true, for all i

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

ניתן יהיה להיענות לדרישותיו בעתיד

שחרר את המשאבים שמחזיק כעת


אלגוריתם הבנקאי – דוגמא“האם המצב הבא של המערכת הוא "בטוח?

ניתן לצמצם אתP2

A B C

P1 0 1 0

P2 2 1 0

P3 1 0 3

Total 3 2 3

A B C

3 1 1

2 1 4

3 2 3

A B C

0 3 4

A B C

3 0 1

0 0 4

2 2 0

Allocation Max Available Need

0 3 4Work

F

F

F

Finish



ניתן לצמצם אתP2 עכשיו, ניתן לצמצם אתP3

A B C

P1 0 1 0

P2 2 1 0

P3 1 0 3

Total 3 2 3

A B C

3 1 1

2 1 4

3 2 3


Work

A B C

0 3 4

Finish

A B C

3 0 1

0 0 4

2 2 0

2 4 4

F

T

F



ניתן לצמצם אתP2 עכשיו, ניתן לצמצם אתP3 עכשיו, ניתן לצמצם אתP1

A B C

P1 0 1 0

P2 2 1 0

P3 1 0 3

Total 3 2 3

A B C

3 1 1

2 1 4

3 2 3


Work

A B C

0 3 4

Finish

A B C

3 0 1

0 0 4

2 2 0

3 4 7

F

T

T



ניתן לצמצם אתP2 עכשיו, ניתן לצמצם אתP3 עכשיו, ניתן לצמצם אתP1

A B C

P1 0 1 0

P2 2 1 0

P3 1 0 3

Total 3 2 3

A B C

3 1 1

2 1 4

3 2 3


Work

A B C

0 3 4

Finish

A B C

3 0 1

0 0 4

2 2 0

3 5 7

T

T

T


Watchdog מכניזם פרקטי, הממומש בחומרה

מונה חומרה מיוחד שסופר אחורה כשהמונה מתאפס, מבצעreset להתקן )מכבה ומדליק

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

התחלתי אם יש קפאון – החוטים לא יעדכנו את המונה ויהיהresetמחייב שיתוף פעולה של החוטים העובדים,אם רוצים לוודא שאף חוט לא מעורב בשום קפאון

צריך להשתמש ברגיסטר נפרד לכל חוט


בתוכנהWatchdogמימוש כמו בחומרה, רק שחוט מיוחד בודק את המונה ואם :1שיטה

מגלה שלא עודכן הרבה זמן, הורג את התהליך מחייב שיתוף פעולה של כל החוטים העובדים

מנסה, אחת לכמה זמן, לתפוס את כל A חוט מיוחד :2שיטה המשאבים במערכת לפי סדר נתון ואז לשחרר

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

בקיפאון, הורג את התהליך )וכל החוטים(Aמניח שחוט מחייב ידע של חוטA לגבי כל משאבי התוכנית, אבל לא מחייב שיתוף

פעולה של כל החוטים העובדים( השיטה פוגעת קצת בביצועי התוכניתintrusive כי )Aתופס משאבים


פסיקותסוגי פסיקות איך מערכת ההפעלה מטפלת

בפסיקותדוגמא: קלט בעזרת פסיקות


?מהן פסיקותפסיקות( interrupts ) הן אירועים הגורמים למעבד

להשעות את פעילותו הרגילה ולבצע פעילות מיוחדת.

שימושים:.מימוש קריאות מערכת-הפעלה קבלת מידע וטיפול ברכיבי חומרה )שעון, חומרת

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


סוגי פסיקות נוצרות על-ידי רכיבי חומרה שונים:אסינכרוניותפסיקות

.ללא תלות בפעילותו הנוכחית של המעבדלמשל: פעימה של שעון המערכת, לחיצה על מקש במקלדת...

נוצרות בשל פעילות של המעבד:סינכרוניותפסיקות .למשל, כתוצאה מתקלות שונות חריגותנקראות גם( exceptions.)

אשר , פסיקות יזומותסוג אחר של פסיקות סינכרוניות הוא(:software interrupts )פסיקות תוכנהנקראות גם

למשל( נוצרות על-ידי הוראות מעבד מיוחדותint.) ,שימושים: מימוש קריאות מערכתdebugging.


הזדמנות שנייהביצוע הוראות מסוימות יכול להכשל ולגרום לפסיקה סינכרונית מעבדים מודרניים מאפשרים למערכת ההפעלה, על-ידי טיפול

בפסיקה, לתת להוראות "הזדמנות שנייה" להתבצע )נקראות restartable instructions)

ההוראה נכשלהפסיקה מערכת-ההפעלה מטפלת בפסיקה.)מריצים שוב אותה ההוראה )שהפעם אמורה להצליח

שימושי למימוש זיכרון וירטואליבהמשך הקורס


אם המעבד מגלה שהיו פסיקות לאחר ביצוע פעולה...

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

.במחסנית המשתמש.אולי מידע נוסף

רגיסטרים מיוחדיםמידע נוסף לגבי הפסיקה, למשל, סוג השגיאה המתמטית.

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


איך מפעילים?את שגרת הטיפול בפסיקה

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

נקרא לפעמים( לכל פסיקה יש מספר שונהinterrupt vector.).למעבד יש גישה לטבלה של מצביעים לשגרות טיפול בפסיקה

.מספר הכניסות בטבלה כמספר וקטורי הפסיקות במעבדיIA16 ממש בתחילת הזיכרון( מכילה 0000:0000, הטבלה שמורה בכתובת(

.1KB בתים = גודל מצביע(, סה"כ 4 בתים כ"א )4 כניסות של 256 -ה( טבלת הפסיקות מאותחלת על-ידי חומרת המחשבBIOS.).בטעינה, מערכת-ההפעלה מעדכנת את הטבלה, ומחליפה חלק מהשגרות -מערכות-הפעלה מודרניות לא מסתמכות כלל על שגרות הטיפול של הBIOS ,

ומחליפות את כל הטבלה.


?מי מריץ את שגרת הטיפול בפסיקה.הפסיקה קורה בזמן שתהליך כלשהו רץ.הפסיקה אינה בהכרח קשורה לתהליך זה

.למשל, נגרמה על-ידי חומרה שתהליך אחר משתמש בה

-קוד הטיפול בפסיקה שייך לkernel.ולא לתהליך

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

הנוכחי, אלא למבני נתונים גלובליים של המערכת.


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

...המשתמש יכול ללחוץ על המקלדת בכל רגע...מצד אחד, חשוב לטפל בהן במהירות האפשרית

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

מצד שני, טיפול שדורש זמן רב ומתחיל מיד, מתבצע עלחשבון התהליך הנוכחי

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

הטיפול בפסיקה אחרת


פתרון (חלקי): טיפול דו-שלבי בפסיקות אסינכרוניות

חלק עליון( top half:).מורץ כשגרת הטיפול בפסיקה, באופן מהיר ככל האפשר רושם )בתור מיוחד( את העובדה שיש לתת לחומרה הרלוונטית טיפול

הולם )למשל, לקרוא את כל המידע שהגיע מהדיסק(.

חלק תחתון( bottom half:) מורץ בזמן מאוחר יותר, ומבצע את "העבודה השחורה" של הטיפול

בפסיקה..פסיקות אחרות יכולות להתרחש תוך-כדי פעולתו

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

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

.התור אינו ריק, ומריצה את כל השגרות הממתינות


שרשור פסיקות:שינוי שגרת הטיפול

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

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

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

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

.מאפשר לא לבצע את הפעולה המקורית במקרים מסוימים


טיפול בפסיקותבמערכת מרובת-מעבדים

פסיקות סינכרוניות: כל מעבד מטפל בפסיקות שיצר הקוד שהואמריץ.

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

יטפל בפסיקהround-robinבמקרה של שוויון

בנוסף, במערכות מרובות-מעבדים יש גם פסיקות המשמשותלהעברת מידע בין המעבדים עצמם

Inter-Processor Interrupts מעבד רואהIPIsשל מעבדים אחרים כפסיקות א-סינכרוניות רגילות .


1דוגמא: קריאה מהדיסק המשתמש מבצע fread כדי לקרוא מידע מהקובץ

fread(...)

מציאת המקום על הדיסק בו שמור המידע

)ע"י קריאת טבלאות, למשל(

:מעבירים לדיסק בקשה

נא לקרוא את המידע מכתובת כך-וכך, ולשמור

...במיקום זה-וזה בזיכרון


2דוגמא: קריאה מהדיסק התהליך שביצע את הקריאה ממתיןבינתיים, רצים תהליכים אחרים...

:פסיקה אסינכרונית

הדיסק סיים את בקשת הקריאה )המידע המבוקש

כבר נמצא בזיכרון(


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

מסתיים הטיפול בפסיקה.בהמשך, מורץ החצי התחתון:

.בודק שהמידע שהדיסק העביר לא כולל דיווח על שגיאות מעביר את התהליך שביצע את הקריאה ממצב המתנה אל

תור המוכנים..אולי גם מעדכן את העדיפות של אותו תהליך

התהליך חוזר מהקריאה fread ומקבל את המידע.


ניהול זיכרון.מבוא: מטרות ניהול הזיכרון :מנגנונים

.מרחב כתובות וירטואלי / פיזי .חלוקת זכרון קבועה מול דפדוף .ניהול טבלת הדפים .מדיניות החלפת דפים


ניהול הזיכרון:מערכת ההפעלה צריכה לנהל את השימוש בזיכרון

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

מערכת ההפעלה צריכה למנוע מתהליך גישה לזיכרוןשל תהליכים אחרים.


Swapping זיכרון של תהליך שאינו

רץ מועבר לדיסק (swap-out.) ,כאשר תהליך חוזר לרוץ

מקצים לו מחדש מקום ומביאים את הזיכרון שלו

(swap-in.)

דורש מנגנון תמיכה...

זיכרון

המשתמש

זיכרון

מערכת הפעלה

P3

דיסק

זיכרון ראשי )פיזי(

P2 P1

P1

P2


מרחב הכתובות של התהליך (תזכורת)

0x00000000

0xFFFFFFFF

address space

code)text segment(




ProgramCounter

StackPointer


מרחב הכתובות של התהליך בעיקרון, כל מרחב הכתובות צריך להיות זמין בזיכרון

הפיזי של המחשב, כאשר התהליך רץ...= 232 מחשב עם זיכרון פיזי בגודל ביטים 32כתובת של

4GB?

... ומה עם דרישות הזיכרון של תהליכים אחרים?

הזיכרון הזה?כלהאם תהליך באמת צריך את ... בכלל משתמש בו?

השטח הכולל שבשימוש קטן בהשוואה למרחב הזיכרון כולו

.מקצים זיכרון רק אם משתמשים בו


חיסכון בזיכרון הזמן?כלהאם תהליך באמת צריך את כל הזיכרון הזה

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

:תהליך ניגש רק לחלק מזערי של עקרון הלוקליות הזיכרון שברשותו בכל פרק זמן נתון

צריך לאחסן ערכים של משתנים, גם אם לאמשתמשים בהם...

אבל לא בזיכרון הפיזי!


זרוק אותו לדיסק!הדיסק מכיל חלקים

מהזיכרון של תהליך שרץ כרגע.

צריך לזכור מה נמצאבזיכרון הפיזי ואיפה )ונמצא

בדיסק(. צריך לבחור מה להעביר

לדיסק. צריך לזכור איפה שמנו

חלקי זיכרון בדיסק, כדי לקרוא אותם בחזרה, אם

נצטרך אחר-כך.

זיכרון

המשתמש

P3דיסק


P1


זיכרון וירטואלי (ממעוף הציפור).מרחב כתובות מלא לכל תהליך

.יכול להיות גדול מגודל הזיכרון הפיזי.רק חלקי הזיכרון הנחוצים כרגע לתהליך נמצאים בזיכרון הפיזי

.תהליך יכול לגשת רק למרחב הכתובות שלו

מוגבל בגודל הזיכרון הפיזי במחשב.פיזימרחב כתובות : אותו רואה כל תהליך.וירטואלימרחב כתובות

.)אינו מוגבל בגודלו )אלא על-ידי גודל הדיסק


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

תהליך זה בלבד.

שמירה על אי-תלות בביצועים. מערכת ההפעלה מחלקת משאבים מצומצמים בין כמה

תהליכים.)של תהליך לא על-חשבון תהליך דרישות הזיכרון )פיזי

אחר.


שיטה ישנה: חלוקה קבועה מערכת ההפעלה מחלקת את הזיכרון הפיזי לחתיכות

שיכולות להכיל חלקים ממרחב sizeבגודל קבוע הכתובות של תהליך.

.לכל תהליך מוקצית חתיכת זיכרון פיזי.מספר התהליכים הרצים ≥ מספר החתיכות


P1

P2

P3

P4

basep

basev

)בדיסק( P2זיכרון וירטואלי של תהליך


בעיות עם חלוקה קבועה.החלפה של חתיכת זיכרון שלמה בבת אחת

:עבודה עם כתובות זיכרון רציפות )אם גדול מספיק להכיל כל מה שצריך )וגם מה שבאמצע

.כל החלפה לוקחת הרבה זמן מאפשר מעט חתיכות שונות

.מעט מידי תהליכים רצים בו-זמנית


שברור פנימידרישות זיכרון שונות לתהליכים שונים.

חלק מחתיכת הזיכרון של התהליך מבוזבז

(internal fragmentation)

P1 P2 P3 P4 P5


שיטה ישנה נוספת: חלוקה משתנה הרחבה של השיטה הקודמת, על-ידי תוספת רגיסטר

המציין את אורך החתיכה.

...מונע שיברור פנימי

?כמה מקום להקצות לתהליך שמגיע


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

external fragmentation

P1 P2 P3 P4 P5

P6


שיטה מודרנית: דפדוף מחלקים את הזיכרון

בגודל דפיםל הוירטואלי(.pagesקבוע )

גדולים מספיק לאפשרכתיבה / קריאה יעילה

לדיסק. קטנים מספיק לתת

גמישות. = 4גודל טיפוסיK. הזיכרון הפיזי מחולק

( frames )מסגרותלזיכרון מדומהבגודל דף

זיכרון פיזי

דיסק


דפדוף כל מסגרת בזיכרון הפיזי

יכולה להחזיק כל דף וירטואלי.

כל דף וירטואלי נמצאבדיסק.

חלק מהדפיםהוירטואליים נמצאים

בזיכרון הפיזי.זיכרון מדומה


דיסק


מנגנון התרגום צריך למפות מכתובת

וירטואלית לכתובת פיזית )בזיכרון הראשי או

בדיסק(.

?איזה דף נמצא איפה...ומהר.דורש תמיכת חומרה

זיכרון מדומה


דיסק

מנגנון/ מיפויתרגום


טבלת הדפים.אחת לכל תהליך כל כניסה בטבלת הדפים מתייחסת למספר דף

וירטואלי של הכניסה.האינדקסזהו

ומכילה מספר מסגרת פיזית הכניסה.ערךזהו

:לכתובת יש שני חלקים( מספר הדףVirtual Page Number.)offset.)מיקום בתוך הדף(


מיפוי הVPN מהווה מצביע לטבלת הדפים ומאפשר למצוא

Physical Pageאת מספר המסגרת שבו נמצא הדף )Number.)

offsetהוספת ה

נותנת את

הכתובת עצמה.

כתובת וירטואלית

Virtual page# offset

Page frame#

כתובת פיזית

Page frame# offset

Page table


דוגמא ביט.32כתובת וירטואלית של-

232מרחב הכתובות מכיל =( 4כתובותGB.)

דפים עםK4 (= 212).כתובות 12 -ביטים ל offset.20 -ביטים ל VPN.

כתובת וירטואלית

תתורגם ל

00000000011100000000110000000000

00000000100100000000110000000000


כניסות בטבלת הדפיםמכילות גם מידע ניהולי, בנוסף למיקום הדף הפיזי:

valid bit.האם הכניסה רלוונטית :.מודלק כאשר הדף בזיכרון, כבוי אם הדף נמצא רק בדיסקreference bit.האם ניגשו לדף :

.מודלק בכל גישה לדףmodify bit.האם הייתה כתיבה לדף :

.בהתחלה כבוי, מודלק כאשר יש כתיבה לדףprotection bits.מה מותר לעשות על הדף :

Page frame# V protectR M


Page Fault כאשר החומרה ניגשת לזיכרון לפי טבלת הדפים

ומגיעה לדף שאינו בזיכרון הפיזי, נגרמת חריגה מסוג page fault

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

ייתכן שיהיה צורך לפנות דף ממסגרת בזיכרון לצורך טעינת הדףהחדש

... כולל כתיבת הדף הישן לדיסק אם הוא עודכן

כאשר מסתיים הטיפול בחריגה, מבוצעת ההוראה מחדשrestartable instruction

Page Fault יכולה להגרם גם מסיבות אחרות: גישה לא חוקית לזיכרון, גישה לדף לא מוקצה ועוד


דפדוף: הטוב:חוסך שיברור חיצוני

.כל מסגרת פיזית יכולה לשמש לכל דף וירטואלי.מערכת-ההפעלה זוכרת איזה מסגרות פנויות

:מצמצם שיברור פנימי.דפים קטנים בהרבה מחתיכות

:קל לשלוח דפים לדיסק.בוחרים גודל דף שמתאים להעברה בבת-אחת לדיסק ביט( לא חייבים למחוק, ניתן רק לסמן כלא-רלוונטיV.)

.אפשר להחזיק בזיכרון הפיזי קטעים לא-רציפים


דפדוף: הרע:גודל טבלאות הדפים

4 ,כניסות 220 בתים לכל כניסה 4טבלת דפים בגודלMB.לכל תהליך תהליכים???20ואם יש .תקורה של גישות לזיכרון

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

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

(.disk latencyמחפים על שהּות בגישה לדיסק )


טבלת דפים בשתי-רמות חוזרים על אותו תעלול, ושולחים חלקים מטבלת

הדפים לדיסק. למשל, דפים של טבלת הדפים שמתייחסים לתהליכים לא

פעילים..רמה נוספת של הצבעה

מאפשרת למצוא את הדפים של בריבועטבלת דפים טבלת הדפים.


חלוקת הכתובת בשתי-רמות:לכתובת וירטואלית יש שלושה חלקים

רצוי שהטבלה ברמה העליונה תכנס בדף אחדKB4 = 1024 בתים.4 כניסות כל-אחת עם ביטים.10החלק העליון של הכתובת צריך להיות עם ביטים.10גם החלק התחתון

Virtual page# offset

secondary page# offsetmaster page#


טבלת דפים בשתי-רמות: מיפויכתובת וירטואלית

Secondary page table

כתובת פיזית

Page frame# offsettop-level page table

secondary page# offsetmaster page#

Page frame#

page table


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

על כל גישה לדף.

פתרון?

מיוחד. (cacheשימוש במטמון )

קטן וזריז...


Translation Lookaside Buffer (TLB)

מטמון חומרה אשר שומר מיפויים )=תירגּומים( שלמספרי דפים וירטואליים למספרי דפים פיזיים.

למעשה, שומר עבור כל מספר דף וירטואלי את כל הכניסהשלו בטבלת הדפים, אשר יכולה להכיל מידע נוסף )זהו

(.הערךהוא מספר הדף הוירטואלי.המפתח :סך-הכל 16-48קטן מאוד( כניסות KB64-192.) תוך( מהיר מאוד: חיפוש במקבילcycle.)אחד או שניים

הרווחנו.( hit)פגיעה, TLBאם כתובת נמצאת ב

תרגום רגיל דרך טבלת הדפים.( missאם יש החמצה )


TLBביצועי ה מאפשר תרגום עבורKB64-192.כתובות זיכרון

אם תהליך ניגש ליותר זיכרון יותר החטאות ב TLB.

של הכתובות!99%פגיעֹות כמעט ב ( מידה רבה של מקומיּותlocality.בגישה לזיכרון )

( לוקליות במקוםspatial locality.מסתובבים בכתובות קרובות :)

.(x+d, סיכוי טוב שאגש לכתובת x)אם ניגשתי לכתובת ( לוקליות בזמןtemporal locality חוזרים לאותן כתובות בזמנים :)

קרובים.

.(t+Δ, סיכוי טוב שאגש אליה גם בזמן t בזמן x)אם ניגשתי לכתובת


כמה זיכרון פיזי תהליך צריך באמת? ,לתהליכים שונים

דרישות זיכרון שונות.

אם תהליך משתמשבאופן פעיל בהרבה

זיכרון, אין מה להריץ אותו כאשר הזיכרון הפיזי

מלא מידי.


Working set קבוצת העבודה של תהליךP, WSP(w)

הגישות האחרונות.w ניגש ב P= הדפים אליהם תהליך

עבור ערך( ככל שהקבוצה קטנה יותרw יש יותר )קבוע מקומיּות בגישות לזיכרון של התהליך.

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

זמן 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

# דף 2 6 1 5 7 7 7 7 5 1 6 2 3 4 4 4 3

WS(3) 2 26

261

6 1 5

1 5 7

5 7

7 7 5 7

5 7 1

5 1 6

2 6 1

263

243

43 4 43


דפדוף לפי דרישה( מביאים דף רק אם התהליך דורש אותוdemand

paging) למשל, בהתחלת הביצוע ניגשים לדפים חדשים, של נתונים

ושל קוד. אם הדף לא נמצא בזיכרון, קורהpage fault.

,לעומת זאתprepaging מנסה לנבא איזה דפים ידרשו, ומביא אותם מראש.

.גישה לדיסק תוך כדי חישוב אחר במעבד


מדיניות ההחלפהאת מי מפנים?

.מטרה עיקרית: מזעור מספר פסיקות הדף.מחיר פינוי דף "מלוכלך" יקר יותר מאשר פינוי דף נקי

:מתי עושים מה טיפול בפסיקת דף מתבצעon-line.( תהליך פינוי דפים מתבצע בדרך-כלל ברקעoff-line ,)

כאשר מספר המסגרות הפנויות יורד מתחת לאיזשהו סף. "לפי עקרון "סימני המים(water-marks).

.דפים מלוכלכים נכתבים ברקע לדיסק


FIFOאלגוריתם מפנה את הדף שנטען לפני הכי הרבה זמן

A B C D A B C D A B C D

0 A A A D D D C C C B B B

1 B B B A A A D D D C C

2 C C C B B B A A A D


Belady אנומליית FIFOבאלגוריתם

A B C D A B E A B C D E

0 A A A D D D E E E E E E

1 B B B A A A A A C C C

2 C C C B B B B B D D

0 A A A A A A E E E E D D

1 B B B B B B A A A A E

2 C C C C C C B B B B

3 D D D D D D C C C


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

עד לגישה הבאה אליו הוא הארוך ביותר.

A B C A B D A D B C B

0 A A A A A A A A A C C

1 B B B B B B B B B B

2 C C C D D D D D D


Least Recently Used (LRU)מפנה את הדף שהגישה האחרונה אליו היא המוקדמת

ביותר

A B C A B D A D B C B

0 A A A A A A A A A C C

1 B B B B B B B B B B

2 C C C D D D D D D

A B C D A B C D A B C D

0 A A A D D D C C C B B B

1 B B B A A A D D D C C

2 C C C B B B A A A D

מתנהג כמוהחמדן

מתנהג כמוFIFO


LRUמימוש חותמת זמן(timestamp)לכל דף

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

ניהול מחסניתבגישה לדף מעבירים את הדף לראש המחסניתמפנים את הדף בתחתית המחסנית

יקר ודורש תמיכה בחומרה


LRU:מקורב אלגוריתם ההזדמנות השנייה

reference bit.לכל דף .בגישה לדף, הביט מודלק בפינוי דפים, מערכת ההפעלה עוברת באופן מחזורי

על כל הדפים אםreference bit = 0.הדף מפונה , אםreference bit = 1.מאפסים את הביט ,


LRUמקורב: שיבה טובה :בגישה לדף מבצעים

R = 1

כל יחידתtimer עבור כל ,דף בזיכרון הפיזי מבצעים:

if (R) then

age = 0

R = 0

else

age++

if ( age > threshold )

evict page

( מצרפים שדה גילage )לכניסה של דף בטבלת

הדפים.

דפים שלא ניגשו אליהםהרבה זמן, מפונים מהזיכרון.


Windows NTמדיניות דפדוף ב .לפי דרישה, אבל מביאים קבוצת דפים מסביב אלגוריתם הדפדוף הואFIFO על הדפים של כל

תהליך בנפרד.

-מנהל הזיכרון הוירטואלי עוקב אחרי הworking set של התהליכים, ומריץ רק תהליכים שיש בזיכרון מקום

שלהם.working setלכל ה--גודל הworking set נקבע עם התחלת התהליך, לפי

בקשתו ולפי הצפיפות הנוכחית בזיכרון.


Linux (2.4.X)מדיניות דפדוף ב גם כאן לפי דרישה, ומביאים קבוצת דפים מסביב

דפים סמוכים מאוחסנים יחד בדיסק ונטענים יחד כשאחד מהם נדרש

-אלגוריתם הדפדוף הוא גלובלי - קירוב לLRU

שלוש הזדמנויות + ניהול מחסנית .כל גישה נותנת הזדמנות אחת נוספת-דומה לLFU (Least Frequently Used כל הדפים בזיכרון הפיזי נמצאים במחסנית, ממוינת לפי מספר

ההזדמנויות. 1 הזדמנויות ועובר מיד לאיזור של 0דף שנטען לזיכרון מתחיל באיזור

)כשניגשים אליו(. פינוי דפים מבוצע מתחתית המחסנית


Linux (2.4.X)מדיניות דפדוף ב הדיסק מופעל כאמצעי אחרון בלבד

דפים מפונים רק כאשר הזיכרון הפיזי מתמלא מעבר לסףהעליון

...ואז מפנים עד מתחת לסף תחתון

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

התהליכים )"הג'יגהבייט הרביעי"(


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

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

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

.אפשר לשתף קוד, אסור לשתף מחסנית זמן-ביצוע

.שילוב עם דפדוף


IA32בסביבת Linux דוגמא: מערכותIA32מאפשרות שילוב של סגמנטציה ודפדוף

סגמנט מוגדר כאוסף רציף של דפים וירטואליים

Windows מנצלת תמיכה זו וממש יוצרת לכל תהליך סגמנט נפרד לקוד, סגמנט נפרד לנתונים וכו'

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

בסגמנטציה

,עם זאתLinux מכילה מנגנון סגמנטציה פנימי בצורה של איזורי זיכרון

שלוש-רמותדפדוף של כל הסגמנטים עם טבלת דפים עם.


מערכת הקבציםמבוא: מטרות מערכת קבצים מנשק המשתמש: פעולות על קבצים, ארגון

קבצים, הגנה.תכונות של דיסקים מימושים: בסיסיים וקצת על מימושים

מתקדמים..אמינות מערכת הקבצים


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

וארוך..למרות הפעלות חוזרות של תוכנית, איתחולים, ונפילות

:מטרותהפשטה מתכונות ספציפיות של ההתקן הפיזי

,גישה דומה לדיסקCD-ROM, DVD... ,טייפ ,.זמן ביצוע סביר.ארגון נוח של הנתונים( הפרדה בין משתמשים שוניםprotection.)( הגנהsecurity.)


מבנה לוגי של מערכת קבצים קבציםאוסף של.הוא מידע עם תכונות שמנוהלות על-ידי קובץ

המערכת..מכיל מספר בתים/שורות/רשומות בגודל קבוע/משתנה קובץ יכול להיות מסוג מסוים

,חלק מהסוגים מזוהים על-ידי המערכת: מדריךlink, mount :או על-ידי אפליקציות....jpg, .html, .doc, .exeבמקביל, ניתן להתייחס לתכולת הקובץ: בינארי או טקסט


)Attributes(תכונות של קובץ תכונות מערכת

שם ?תווים מּותריםupper / lower case.

גודל, בדרך-כלל בבתים.מיקּום.מידע על בעלות והגנה.תוויות זמן: יצירה, גישה אחרונה, שינוי אחרוןתכונות משתמש

-בHPFS מערכת הקבצים של( OS/2 ) ⟨attribute_name,string⟩ניתן להצמיד לקובץ זוגות

(.GB2)מחרוזת באורך עד


פעולות בסיסיות על קבצים:יצירה/השמדה של קובץ

create.מקצה מקום לקובץ, ושומר את התכונות שלו :delete משחרר את המקום שהוקצה לקובץ, וכן את :

התכונות שלו.

:קריאה/כתיבהread נותן שם קובץ, כמות מידע לקריאה וחוצץ זיכרון שבו :

יאוחסן המידע הנקרא; מתחזק מצביע מיקום לקובץ.write נותן שם קובץ ומידע לכתיבה; מתחזק מצביע מיקום :

לקובץ.seek.הזזת מצביע המיקום :


פעולות נוספות על קבציםopen, close

מאחזרות מידע על הקובץ, מאתחלות את מצביע המיקוםלקובץ.

.משפרות את ביצועי המערכת

append, rename, copy ,…...ניתן לממשן בעזרת פקודות אחרות

.נעילהעדכון תכונות הקובץ


אופני גישה לקובץ ניגשים למידע בקובץ לפי סדר.סדרתיתגישה :

.בד"כ מהירה יותר לא צריך לציין מהיכן לקרוא )ניתן להתבסס על מצביע

המיקום(..מאפשר למערכת להביא נתונים מראש

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


ארגון מערכת קבציםמספר הקבצים מגיע לאלפים

!ישנן מערכות שמכילות מיליארדי קבצים

מחיצות (partitions) בד"כ לפי התקנים ,(devices.)מדריכים (directories) טבלאות הקבצים בתוך ,

המחיצה.


מדריכים המדריך הוא מבנה נתונים מופשט, אשר שומר את

התכונות של כל קובץ הנמצא בו.

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

...


מבנה מדריכים: עץ מכוון עץ בעל מספר רמות שרירותי(MS-DOS)

המדריך הנוכחימושג( current directory.) קובץ מזוהה ע"י מסלול מהשורש )מוחלט( או מהמדריך

הנוכחי )יחסי(.

d1 d2 d3 d4 d5

d1-1 d1-2 f1 f2 f3 d2-1 d2-2 f1

d1-1 d1-2 f1 f2


מבנה מדריכים: גרף אציקלי בגרף אציקלי, מאפשרים

למספר כניסות במדריכים )אולי שונים( להצביע לאותם

(Unix)העצמים

למה לא לאפשר מעגליםבגרף?


סוגי קישורים סימבולי / רךקישור( soft / symbolic link :)

כניסה שמכילה את המסלול לקובץ. חזקקישור( hard link :)

לא ניתן להבדיל מהכניסה המקורית

:מחיקת קובץקישור סימבולי אינו מונע מחיקת הקובץ

משאיר מצביע תלוי באוויר

.קישור חזק מחייב מחיקת כל הכניסות


Unixמבנה מדריכים ב-...שם )מסלול מלא( אינו תכונה של קובץ

לאותו קובץ ניתן להגיע דרך מסלולים שונים

מחזיקיםuse-counter שמאפשר לדעת מתי למחוק קובץ.

תהליך יכול ליצור קובץ, לפתוח אותו, למחוק את הכניסה)היחידה( שלו מהמדריך ולהמשיך לעבוד עליו

.לתהליך מבנה נתונים של קבצים פתוחים בד"כ כולל מידע על מיקום נוכחי בקובץ שאינו משותף עם

פתיחות אחרות של אותו קובץ, כולל של אותו תהליך.


הגנה רוצים למנוע ממשתמשים לבצע פעולות ספציפיות

על הקובץ )בשוגג או במזיד(... ,למשל קריאה, כתיבה, ביצוע, שינוי שם

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

:נקבץ משתמשים למחלקות שונותowner, group, universe… :מספר מוגבל של פעולותread, write, execute


נעילת קבציםadvisory locking

)תהליך צריך לנעול קובץ בצורה מפורשת )כמו קטע קריטיאפשר לנעול קובץ שלם או חלקים מהקובץ

mandatory locking אם הקובץ נעול – כל תהליך שמבצעread, write, open יינעל, גם

אם לא ביצע נעילה מפורשת

(reader/writer lockאפשר להפריד לפי קריאות וכתיבות )mandatory locking וגם advisory locking יש גם Linuxב

leases אם תהליך שנעל את הקובץ לא משחרר אותו ולא מאריך את הlease

תוך פרק זמן נתון, המנעול משתחררשימושי אם התהליך שנעל את הקובץ נפל


היררכית האחסון

DVD, CDאמצעי גיבוי,

DISK

DRAMזיכרון ראשי / פיזי

מטמון

רגיסטרים

ר(ת

יוול

וז(

תר יו

ולגד תר

היר יומ

נדיף

לא-נדיףPersistent

Volatile


זיכרון משני בניגוד לזיכרון הראשי, אינו מאפשר ביצוע ישיר של

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

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

.גישה סידרתית מהירה.קיבולת גבוהה


מבנה מערכת קבצים טיפוסיתApplicationApplication ApplicationApplication

File System APISystem-call Interface

Logical File System

logical file system קוד כללי, בלתי תלוי

במערכת קבצים ספציפית ,קוד שמקבל מסלול

ומחזיר את קובץ היעד ניהול מידע כללי עבור

קבצים פתוחים, כמו מיקום בקובץ...

.פעולות על מדריכים.הגנה ובטיחות




Logical File System

Virtual File System Interface

logical file systemvirtual file system

interface מנשק אחיד לכל מערכות

הקבצים הספציפיות. למשלvfs_read,

vfs_write, vfs_seek.




Logical File System


PhysicalFile

System 1

PhysicalFile

System 4


interfacephysical file system

-מימוש מנשק הVFS עבור מערכת קבצים ספציפית

,למשל, מעל דיסק רשת, RAM, CDדיסקט,

וכו‘ מתכנן איך לפזר את

הבלוקים..בהמשך, נתרכז בו




Logical File System


PhysicalFile

System 1

PhysicalFile

System 4

Device Driver Device Driver

IBM

Device DriverDevice Driver

Seagate


interfacephysical file systemdevice drivers

קוד שיודע איך לפנותלהתקן ספציפי

,)דיסקים )לפי מודלDVD ,וכדומה.

מתחיל את הפעולההפיזית, ומטפל בסיומה.

מתזמן את הגישות, עלמנת לשפר ביצועים.


מבנה הדיסק

head

sectortrack

cylinderמבנה כתובת (CHS )Cylinder, Head, Sector

או(LBA )Logical Block Array

plate


שימו לב ש•

זמן ממוצע לגישה לסקטור אקראי• 4KB זמן העברה פנימי של סקטור •

)seagateדוגמא: דיסק של שרת (

sec6.526.3 mls sec45/4 trKB

1

2l

r

1000$עלות -

rסיבובים לדקה

l זמן ממוצע מהגעה עד לסקטורtrackל-

tr קצב העברת נתונים

s זמן ממוצע להזזתtrack ל-trackזרוע מ-


desktop (IBM)דוגמא: דיסק של

sec67.1217.45.8 mls

100$עלות -


מימוש מערכת קבצים: מדדיםמהירות גישה סדרתית מהירות גישה אקראית

)ישירה(שיברור פנימי וחיצונייכולת להגדיל קובץהתאוששות משיבושי מידע


מיפוי קבצים: הקצאה רציפהבבלוקים באורך קבוע

כפולה של גודל סקטור(512B – 4KB)נע בין

המשתמש מצהיר על גודלהקובץ עם יצירתו.

מחפשים בלוקים רצופיםשיכולים להכיל את הקובץ.

הכניסה במדריך מצביעהלבלוק הראשון בקובץ.

file1file2file3 5

66


מיפוי קבצים: הקצאה רציפה גישה מהירה )סדרתית

וישירה(שיברור פנימי וחיצוניקשה להגדיל קובץ

file1file2file3 5

66


מיפוי קבצים: הקצאה משורשרת.כל בלוק מצביע לבלוק הבא הכניסה במדריך מצביעה

לבלוק הראשון בקובץfile1


מיפוי קבצים: הקצאה משורשרת.קל להגדיל קובץ.מעט שיברור חיצוני גישה איטית, בעיקר לגישה

ישירה. שימוש בבלוקים גדולים מקטין את

הבעיה, אך מגדיל שיברור פנימי.

שיבוש מצביע בבלוק גורםלאיבוד חלקים של קובץ.

file1


הקצאה משורשרת: מצב הדיסק

מדריך

סוףהתחלהקובץ

foo 814


File Allocation Table (FAT) החזקת שרשרת המצביעים

בנפרד.

file1


File Allocation Table (FAT) .החזקת שרשרת המצביעים בנפרד מצביע הקובץ )במדריך( מראה על

הכניסה הראשונה. בעצם, טבלה שמתארת את התוכן של

הדיסק כולו.

MS-DOS.

file1


FATמגבלות של 216הטבלה נמצאת במקום נוח בדיסק / זיכרון ראשי, ומכילה

ביטים(16כניסות )אינדקס של .כאשר הדיסקים גדלים, גודל החתיכות גדל

6.4דיסק שלGB 100 היה מחולק לחתיכות שלKB הוא שכיח(.10-20%מגדיל את השיברור הפנימי )בזבוז של 2לדיסקים מעלGB-משתמשים ב ,FAT-32 כניסות232, עם

.כל קובץ דורש לפחות חתיכה אחת 64לכל היותרK-קבצים ב FAT, 4G-ב FAT-32.

טבלת הFAT.מהווה משאב קריטי .צוואר בקבוק בגישהלאובדן הטבלה או לפגיעה בה יש משמעות קטסטרופאלית

...ולכן היא מוחזקת בשני עותקים


מיפוי קבצים: אינדקס המשתמש מצהיר על

גודל קובץ מקסימלי. המצביעים לבלוקים

מרוכזים בשטח רצוף משפר במקצת את זמן

הגישה הישירה לעומת הקצאה משורשרת.

צריך להצהיר מראש עלגודל קובץ

file1


אינדקס: מצב הדיסק

מדריך

בלוק אינדקסקובץ

foo 15


מיפוי קבצים: אינדקס מרובה רמות

modeownerstimestamps#blocks…

inodedirectoryfile1file2file3file4

directblocks

single indirectiondouble indirectiontriple indirection

datadatadata

datadata

datadatadata

data

data

data

data

data


Unix 4.1מבנה מערכת הקבצים ב inodes (index nodes) ,אינם מדריכים

אלא בלוקים רגילים מדריכים הינם קבצים רגילים אשר ממפים שמות

קבצים .inodesל

לאחר שימוש ממושך במערכת הקבצים:.בלוקים שונים של אותו קובץ נמצאים רחוק זה מזהinodes ובלוקי אינדקס נמצאים רחוק מבלוקים של

מידע.


Unix 4.2 Fast File System (FFS)

.)קבוצות של צילינדרים קרובים )על הדיסק:בתוך אותה קבוצת צילינדרים משתדלים לשים

בלוקים של אותו קובץ כולל( בלוקים של אותו מדריךinodes.)

:בתוך קבוצות שונות שמים.בלוקים של קבצים ממדריכים שונים

מקום פנוי בכל קבוצת צילינדרים.10%~שומרים על


bitmapניהול בלוקים פנויים: .מערך ובו סיבית לכל בלוק

0 ;הבלוק פנוי.1 – הבלוק תפוס

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

4עם בלוקים שלKB נזדקק לבלוק של , בלוקים. 4096*8ביטים עבור

.קל לזהות רצף של בלוקים פנויים

0

1

0

1

1

0

1

1

1

0

1

1


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

.מציאת בלוק פנוי בודד מהירה:הקצאה של מספר בלוקים לאותו קובץ

.במקומות המרוחקים זה מזה מציאת הבלוקים מחייבת תזוזות של

הדיסק.

מבנה הנתונים נהרס אם בלוק באמצעהרשימה השתבש.

בFAT הבלוקים הפנויים מנוהלים ,כקובץ אחד.


ניהול בלוקים פנויים: קיּבּוץ שימוש ברשימה מקושרת של

אלמנטים: grouping כל אלמנט מכיל טבלה של -

מצביעים לבלוקים פנויים רצופים ומצביע לאלמנט הבא

counting כל אלמנט מכיל מצביע – לבלוק הפנוי הראשון מקבוצת בלוקים

פנויים רצופים, מספר הבלוקים בקבוצה ומצביע לאלמנט הבא

ניתן למצוא בצורה יעילה מספר גדולשל בלוקים פנויים ורציפים.


אמינות-המידע בדיסק מתחלק ל

user data.)נתוני המשתמש )בתוך הקבצים :metadata.מידע על ארגון הקבצים :

,בלוקים של אינדקסinodes...

איבוד/שיבושmetadata עלול לגרום לאיבוד user data.רב .נפילת חשמל באמצע כתיבה עלולה לשבש את הסקטור שכעת נכתב

?מתי כתיבות עוברות מהזיכרון הראשי לדיסקwrite-through.כל כתיבה עוברת מיידית לדיסק – write-back.הדיסק מעודכן באופן אסינכרוני, אולי לא לפי סדר –


Unixאמינות ב- הdata נכתב במדיניות write-back נתוני המשתמש :

נכתבים באופן מחזורי לדיסק. פקודותfsync, sync מאלצות לכתוב את הבלוקים המלוכלכים

לדיסק.

הmetadata נכתב במדיניות write-through עדכונים :נכתבים מידית לדיסק

נתונים מסוימים נשמרים במספר עותקים-למשל, שורש הfile system

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

הדיסק.ScanDisk, fsck (file system check)


)logging(רישום שיטה יעילה לתחזוקת

metadataה--רושמים בlog סדרתי את

העדכונים לפני שהם נכתבים לדיסק

(write-ahead logging.) הבלוקים שהשתנו נכתבים

לדיסק לאחר-מכן..אולי לא לפי הסדר אפשר לקבץ מספר שינויים

ולכתוב אותם בכתיבה אחת.

log


logהתאוששות עם -לאחר נפילה, עוברים על כל הכניסות בlog

.בצע את הפעולה ביצוע נוסף של פקודה שהתבצעה במלואה או חלקית נותן תוצאה

.(idempotent)שקולה לביצוע הפעולה המקורית

-אם הכניסה האחרונה בlog אינה שלמה, מתעלמים ממנה.

-ניתן למחוק מהlog.עדכונים שכבר נכתבו לדיסק


loggingיתרונות וחסרונות של כתיבה לדיסק באופן אסינכרוני.התאוששות יעילה

תלויה במספר השינויים שלא נכתבו לדיסק, ולא בגודלמערכת הקבצים.

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


log-structuredמערכת קבצים הlogהוא העותק היחיד של הנתונים ( כאשר משנים בלוקdata, header )

.logפשוט כותבים את הבלוק החדש ל -בסוף הlogולכן העותק הישן של הבלוק לא תקף , מפה מיוחדת מאפשרת לדעת איפה כל בלוק

logנמצא ב

דיסקים אופטיים שניתן לכתוב רק פעם המקור:(write-onceאחת )


במערכת קבצים "מסורתית"לפני:

אחרי הוספת בלוק:

אחרי שינוי בלוק:

map

map

data

data

mapdata


Logבמערכת מבוססת לפני:

אחרי הוספת בלוק:

אחרי שינוי בלוק:

map

map

data

data

mapdata


LFS: יתרונות וחסרונות)הכתיבות הן סדרתיות )ולכן יעילות יותר

ישseeksרק עבור קריאות עם מטמון גדול בזיכרון הראשי, רוב הקריאות לא הולכות

לדיסק בכתיבה סדרתית של קובץ, סיכוי טוב שהבלוקים של

(, מבטיח קריאה יעילה logהקובץ רצופים בדיסק )ב בעתיד.

איסוף בלוקים שמתפנים )מה קורה אם הדיסקמתמלא?(

-הזזת הבלוקים התפוסים לתחילת הlog


Logגם את המפה כותבים ב

supermap לפני:

אחרי הוספת בלוק )שינוי בלוק מבוצע באופן דומה(:supermap

supermapמאפשר למצוא את הבלוקים המעודכנים של המפה


LFSמימושים של עבור מערכת ההפעלה 1992המימוש הראשון ב-

Sprite על-ידי Ousterhout and Rosenblum

BSD-LFS מימוש ל BSD ,)היוניקס של ברקלי( NetBSDנמצא ב

LogFS הוא מימוש ל Linux.עבור זיכרון פלאש


אפליקציות שרת-לקוחפרדיגמת שרת לקוח מושג ה socketמבנה שרת-לקוח קצת יותר על רשתות


רשת תקשורת

Internet

שרת


לקוחות ושרתיםלקוח

רץ על מחשב קצהמבקש שרותWeb browser

שרתרץ על מחשב קצהמספק שרותWeb server

GET /index.html

“Site under construction”


תקשורת שרת-לקוח"הלקוח "מזדמן

יוזם בקשה כשמעוניין לא מתקשר עם לקוחות

אחרים צריך לדעת את כתובת

השרת

השרת תמיד עובד מקבל בקשות מהרבה

לקוחות לא יוזם את הקשר עם

הלקוחות צריך כתובת קבועה

וידועה


?socketמהו ( ממשק תכנותAPIליצירת תוכנות רשת )שליחת הודעה מתהליך אחד לתהליך במחשב אחר

צריכה לעבור את הרשת

ההודעה נשלחת ומתקבלת דרךsocket"המובילה מתוך ואל הבית מעין "דלת

socket socket

User process User process

OperatingSystem

OperatingSystem


זיהוי התהליך המקבלהתהליך השולח צריך לזהות את התהליך המקבל

שם או כתובת של מחשב הקצהמזהה של התהליך המקבל

זיהוי מחשב הקצה באופן ייחודי על-ידי כתובתIP (Internet Protocol) ביטים32 בת

זיהוי התהליך המקבלמחשב הקצה מריץ הרבה תהליכים זיהוי התהליך על-ידיport number ביטים16 בן

מושג של רשת התקשורת ולא של מערכת ההפעלה


זיהוי תהליך על-ידי פורט

Web server(port 80)

Client host

Server host 128.2.194.242

Echo server(port 7)

Service request for128.2.194.242:80

(i.e., the Web server)

OS

Client

Service request for128.2.194.242:7

(i.e., the echo server)

Client


באיזה פורט להשתמש?לאפליקציות פופולאריות יש מספר פורט ידוע

לשרת 80למשל web, 25 לשרת mail רשימה ב http://www.iana.org

פורטים ידועים ופורטים זמניים (80לשרת יש מספר פורט ידוע )למשל

1023 ל- 0בין

הקליינט מתקשר דרך מספר פורט זמני 65535 ל 1024בין


Unix במערכות socketממשק ה- הוצג לראשונה בBerkeley Unix

נתמך בכל מערכות ההפעלה הפופולאריותמאפשר העברה חלקה של אפליקציות

דומה לממשק לקובץקבלת מידע היא כמו קריאה מקובץ שליחת מידע היא כמו כתיבה לקובץ -הקובץ והsocket מיוצגים על-ידי integer descriptor

:קריאות מערכת ההפעלהClient: create, connect, write, read, closeServer: create, bind, listen, accept, read, write, close


חלוקת העבודהזיהוי יחיד של התקשורת בין שני מחשבי קצה

שתי כתובותIPושני מספרי פורט ( סוג פרוטוקול התקשורתTCP או UDP)

: מעבירה את ההודעה למחשב היעדהרשת-על סמך כתובת הIP

socketמעבירה את המידע ל- :מערכת ההפעלהעל סמך הפרוטוקול ומספר הפורט

ומטפלת בוsocket: קוראת מידע מה-האפליקציה


מבנה טיפוסי של לקוח:הכנה להתקשרות

יצירתsocketsocket(…)

)מציאת כתובת השרת ומספר הפורט )בד"כ קבועאתחול התקשורת לשרת

connect(sockfd, serv_addr, …)החלפת מידע עם השרת

כתוב מידע לsocket קרא מידע מהsocket למשל, הצג דף( טפל במידעhtml) סגור את הsocket

close(sockfd)


control flow מימוש של שרת-לקוח: Client side

sd=socket)(

connect)sd, dst(

write)sd, …(

read)sd, …(

close)sd(


שרתים אינם לקוחות:מוכנים לתקשורת פאסיביים

אבל לא מתחילים עד ששומעים מהלקוח

שומעים מכמה לקוחות ,צריך לאפשר תור של לקוחות מחכים

אם מספר לקוחות מתחילים התקשרות בו-זמנית

יצירתsocketלכל לקוח ,כאשר מקבלים בקשה מלקוח חדש

חדש )ובלעדי(socketיוצרים עבורו


מבנה טיפוסי של שרת:הכנה להתקשרות

יצירתsocketsocket(…)

-קשר כתובת עצמית ומספר פורט עם הsocketbind(sockfd, my_addr, …)


מבנה טיפוסי של שרת: הקשבה( המתן לשמוע מלקוחpassive open)

ציין כמה לקוחות ממתינים מותרים

listen(sockfd, num)

קבל בקשת התקשרות מלקוח ויצורsocketיעודי accept(sockfd, &addr, … )

-החלפת מידע עם הלקוח על הsocketהחדש קרא מידע מהsocket למשל, הבא קובץ( טפל בבקשהhtml) כתוב מידע לsocket-סגור את ה socket

חזור להמתנה


טיפול בבקשותטיפול סדרתי בבקשות אינו יעיל

כל שאר הקליינטים צריכים להמתין

כדאי שהשרת יטפל בכמה בקשות קליינטים בו-זמנית(time-sharing)קצת עבודה על בקשה אחת, ועבור לבקשה אחרת

...פירוק למשימות קטנות, כמו מציאת קובץ

או יצירת תהליך חדש לטיפול בכל בקשה)או שימוש במאגר חוטים )כמו שראינו בהתחלת הקורס


control flow מימוש של שרת-לקוח: Client side

sd=socket)(

connect)sd, dst(

write)sd, …(

read)sd, …(

close)sd(

Server side

sd=socket)(

bind)sd, port(

listen)sd,…(

new_sd=accept)sd(

read)new_sd, …(

write)new_sd, …(

close)new_sd(

sdמחבר את ה שלו לפורט

מגדיר את אורך מסויםהתור

מקבל בקשה אחת

קריאה חוסמת

שלח בקשה

שלח תשובה

יצירת קשר

רצוי לתת לחוט נפרד לטפל

בבקשה


מודל השכבות :socketמתחת ל

מאפשרים העברת נתונים ברשת, פרוטוקולי תקשורת ופועלים בשכבות שונות, כשלכל שכבה תפקיד

משלה. אוסף פרוטוקולי התקשורת הנפוץ ביותר נקרא

TCP/IP שכבות4מכיל Application (telnet, ftp …) אפליקציות המשתמשות ברשת

Transport (TCP, UDP) תקשורת בין תהליכים )ולא מחשבים(

Internet (IP) ניתוב חבילות בין תחנות )לא שכנות(

Data Link העברת חבילה בין תחנות שכנות


תקשורת בשכבות

Data Link

Internet

Transport

Application

Data Link

Internet

Application

Transport

Source Destination

כל שכבה מקבלת שירותים מהשכבה שמתחתיה

מספקת שירותים לשכבה שמעליה

ו"מדברת" עם השכבה המקבילה במחשב השני


קצת יותר מדויק

כל שכבה מקבלת שירותים מהשכבה שמתחתיה

מספקת שירותים לשכבה שמעליה

ו"מדברת" עם השכבה המקבילה במחשב השני, או במחשבי ביניים

Data Link

Internet

Application

Transport

Destination

Data Link

Internet

Data Link

Internet

Data Link

Internet

Transport

Application

Source


Data Linkשכבת הקו:מעבירה חבילה מהתחנה לתחנה שכנה באותה רשת מטפלת בכל הפרטים הקשורים בחומרה ובממשק

עם הרשת הפיסית. הפרוטוקול שונה מרשת לרשת ותלוי בחומרה של

הרשת הפיסית.נקרא גם MAC (Medium Access control)


IP: פרוטוקול Internetשכבת .אחראית על ניתוב חבילות מתחנת המקור לתחנת היעדהפרוטוקול בשכבה זו נקרא -Internet Protocol IP. מנתב חבילות בין רשתות שונות, באמצעותgateways .

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

אלא רק מחליט איך לנתב כל חבילה.כל חבילה מנותבת בנפרד, ללא קשר לחבילות אחרות

(connectionless)הפרוטוקול הוא


IPכתובות .מספר יחודי המזהה כל ממשק תקשורת שמחובר לרשת

למחשב אחד יכולים להיות מספר כתובותIP ,לדוגמה, אם יש לו כמה כרטיסי רשת

גודל של כתובתIP סיביות. 32 הוא מקובל לייצג כתובתIP מספרים עשרוניים4 ע“י

: 132.68.37.66לדוגמה הניתוב מתבסס על כתובתIP טבלאות ניתוב של החבילה ועל

router, הקיימות בכל ( routing tables)מיוחדותrouter הינו מחשב שדרכו עוברות חבילות שלא מיועדות למחשב

עצמו. – ל router .יהיו בד"כ מספר ממשקי תקשורת -ניתן לגלות כמה ממשקי תקשורת יש למחשב ומה כתובות הIP שלהם

Linux של shell בתוך ifconfigבאמצעות הפקודה


Transport: UDP / TCPשכבת

תהליכים מאפשרת תקשורת בין(מחשבים מאפשרת תקשורת בין IP)שכבת

UDP (User Datagram Protocol):מעביר הודעה בודדת בין שני תהליכים,

מבלי להבטיח סדר או אמינותTCP (Transport Connection Protocol)

בין שני תהליכים, ומבטיח: sessionיוצר :החבילות יגיעו ליעדן בסדר שבו נשלחו סדר אמינות: כל החבילות יגיעו ליעדן )חבילה שהולכת לאיבוד

משודרת מחדש(


שכבת האפליקציה

:מכילה פרוטוקולים של אפליקציות כגון telnet, ftp, http .ואחרות

אפליקציות אלה משתמשות בפרוטוקוליtransport לתקשורת עם מחשבים מרוחקים.


מערכות קבצים מבוזרותמבוא מבנה כללי :דוגמה Network file system :דוגמה Google file system


מערכות קבצים מבוזרותמאפשרות לתהליכים אשר רצים במכונות שונות, גישה ושיתוף

קבצים

אפליקציה שנכתבה לטיפול בקבצים שקיפות לאפליקציה :מקומיים לא צריכה להשתנות.

שם הקובץ לא מכיל מידע על מיקומו שקיפות מקום :)מקומי/מרוחק(.

-בURL)מציינים במפורש את המיקום )אין שקיפות מקום

http://hostname/d1/d2/d3/fשינוי מיקום קובץ לא נראה למשתמש.אי-תלות במיקום :

בAndrew File System (AFS) ניתן להעביר ,volumes משרת לשרת בצורה שקופה לחלוטין.

.מרחב שמות אחיד לקבצים ללא תלות במיקומם


התמונה הגדולה לקוחתהליך רץ במחשב( client) שרת התהליך מבקש לגשת לקובץ הנמצא במחשב(server) מחשב הלקוח ומחשב השרת מחוברים באמצעי תקשורת

כלשהו )כבל תקשורת, רשת מקומית, אינטרנט(

File System

ServerClient


התמונה הגדולה לקוחתהליך רץ במחשב( client) שרת התהליך מבקש לגשת לקובץ הנמצא במחשב(server) מחשב הלקוח ומחשב השרת מחוברים באמצעי תקשורת

כלשהו )כבל תקשורת, רשת מקומית, אינטרנט( כאשר תהליכים בלקוח מבצעים קריאות מערכת לקבצים אצל

השרת: בקשותהלקוח שולח לשרת

מערכת ההפעלה שולחת בקשות בהתאם לקריאות המערכת שלהתהליכים

תשובותהשרת מחזיר.תהליך מיוחד בשרת מאזין לבקשות, מבצע אותן, ומחזיר תשובות

פרוטוקול תקשורתסוגי ההודעות בין הלקוח והשרת מוגדרים ב


File System

ServerClient

שיגור פונקציה :1אפשרות הפעולות מועברות לשרת אשר מבצע אותן לוקלית ומעביר את

(Function Shippingהתוצאות חזרה ללקוח ) למשל( מימוש פשוטRemote Procedure Call)

2. read file id

5. buffer, status

ServiceService

3. read 4. results

ApplicationApplication

Invocation on remote file

1. read 6. results


File System

ServerClient

שיגור נתונים :2אפשרות הנתונים מועברים מהשרת ללקוח, אשר מבצע את הפעולה

(Data Shippingבאופן מקומי )מוריד עומס בשרת?איך יודעים האם הנתונים עדכניים

2.request data(if necessary)

3. data shipped

1. read 6. results

Remote FileHandling

4. read 5. results

ApplicationApplication


מטמון מדיניות משולבת:?מדיניות עדכון: מתי מעבירים עדכונים מהמטמון לשרת

write-throughאמין, אך המטמון מנוצל אך ורק בקריאה :write-backעדכונים אחרונים עלולים ללכת לאיבוד :write-on-closeהשינויים מועברים בעת סגירת הקובץ :delayed-writeהשינויים מועברים כל פרק זמן :

:איך הלקוח יודע שהנתונים במטמון תקפים? קונסיסטנטיותclient-initiated הלקוח בודק בכל גישה, כל פרק זמן או כאשר :

הקובץ נפתחserver-initiated השרת זוכר איזה לקוח מחזיק איזה חלקים של :

קבצים השרת יכול לשלוח הודעהrevokeללקוח אשר פוסל את העותק שלו או, עבור קבצים הפתוחים לכתיבה ע"י מספר לקוחות, מבטלים את

המטמון וניגשים כל הזמן לשרת


יש מצב?האם השרת שומר מצב עבור כל לקוח בין בקשה

לבקשה? למשל, איזה קבצים נפתחו ע"י הלקוח, מיקום בקובץ, מידע

על הנתונים במטמון של הלקוח,מנעולים וכדומה.

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

המידע הדרוש לביצוע הפקודה.


אין מצב!( פרוטוקול בלי מצבstateless.)

.השרת לא שומר מידע.בקשה מכילות את כל המידע הנחוץ לטיפול בהן.קל יותר למימוש.קל להתאושש מנפילות

השרת יכול ליפול ולהתאושש מבלי שלקוחות ירגישו )חוץמאשר האטת זמן התגובה בעת ההתאוששות(.

לא ניתן לבצע שיפורים ולחסוך בתקשורתקשה לממש נעילות של קבצים

השרת לא יכול לזכור שהקובץ נעול


Network File System: NFS.פרוטוקול שרת-לקוח( בעיקרון, בלי מצבstateless.) פעולותRemote procedure call (RPC):

read-ו writeעל קובץ גישה לתכונות של קובץחיפוש בתוך מדריך 'פעולות על מדריכים,כמו חיפוש, הוספת/מחיקת כניסה וכד אין בפרוטוקול פעולותopen-ו close

הלקוח מרכיב(mounts) תת-עץ של השרת במדריך שלו.


Mountהרכבת מדריכים:

/

etc bin usr mail

john

data test

file1 file2 file3

Client/

etc bin usr mail

dan

shared_data1

dir1 dir2 dir3

Server

shared_data2

f1f2

f3

exports

/usr/dan/shared_data1 host1 host2/usr/dan/shared_data2 host1


Mountהרכבת מדריכים:

/

etc bin usr mail

john

data test

Client/

etc bin usr mail

dan

shared_data1

dir1 dir2 dir3

Server

shared_data2

f1f2

f3

exports

dir1 dir2 dir3

f1f2

f3


NFSשקיפות ואי-תלות ב :גישה כמו לקובץ מקומי. שקוף לאפליקציה שקיפות מקום, המשתמש לא מבחין מהו מיקום

הקובץ.-אלא אם הmount pointsידועים לו

:הזזת קובץ מחייבת שינוי ה- יש תלות במיקוםmount


NFSמימוש Applicatio

n

Application

Server

System-call Interface

Logical File System

Physical FileSystem NFS

Client

Device Driver

RPC

Client

Virtual File System Interface Virtual File System Interface

Physical FileSystemNFS

Server

Device Driver

RPC


ביצוע פקודותNFSמבוסס על שיגור הפונקציה לביצוע אל השרת

( לשיפור הביצועים, משתמשים במטמוןcache אצל )הלקוח שאליו קוראים חלקים מהקובץ שאיתו עובדים

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

!כתיבות לקובץ אינן משפיעות מיד אצל לקוחות אחרים

כמעט כל קריאת מערכת )לגישה לקובץ( מתורגמת.RPCישירות לפעולת

היוצאים-מן-הכלל הםopen-ו close אשר מחייבות ,פעולות ניהול מקומיות בלקוח.


Google*מערכת הקבצים של מערכת קבצים ייעודית לתמיכה באפליקציות ספציפיות

( אוספים מידע מכל הרשתcrawling)"מאחסנים על "דיסק אחד גדול" מבצעים חיפושים של לקוחות עלPC"אחד גדול אבל דורש הרבה יותר זיכרון וכוח חישוב ממה שמחשב בודד יכול לתת בלי להשתמש במחשב מקבילי עצום

לפי המאמר:* Ghemawat, S., Gobioff, H., and Leung, S. The Google file system. SOSP 2003


שימוש במצבור של שרתים זולים המון )המון( שרתים, כל אחד עם דיסק וCPU.

מאות ואלפים של יחידותPCסטנדרטיות לחלוטין וזולות ?איך לפזר מידע על פני השרתים?איך לטפל בנפילות

,נפילות של דיסקים, שגיאות תכנות, בעיות חשמל, טעויות אנושבעיות תקשורת, ועוד ועוד

אוליNFSכל הקבצים על שרת אחד, הרבה לקוחות ??צוואר בקבוק?טיפול בנפילות

GFS ,מערכת קבצים על מצבור של שרתים :אשר תוכננה מתוך ידע מדוקדק על צרכי

השימוש בה, עם התאוששות מנפילות באופן אוטומטי וחלק.


GFSשימוש ייעודי : ≥ 100קבצים גדולים מאוד MB( קריאות גדולות ברצףstreaming ≥ )1 MB

Read once כתיבות סדרתיות גדולות שמבצעותappend)כתיבה בסוף(

Write once!על-ידי כמה לקוחות בו-זמנית

אטומיות על תורproducer-consumerללא סנכרון


GFSארכיטקטורה :)שרת ראשי יחיד )עותקים משוכפלים לגיבוי( מאות / אלפי שרתי חתיכותchunk servers)

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


GFSהשרת הראשי : מחזיק את כל הmetadata ,)מרחב השמות )מדריכים :

הרשאות גישה, מיפוי מקבצים לחתיכות, מיקום החתיכות )על שרתי חתיכות(

( מנהל מתן הרשאותleasesעל חתיכות לשרתי החתיכות )מעביר חתיכות בין השרתים

הכול בזיכרון ראשי, על מנת להאיץ את הגישה


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


GFSלקוח : שולח בקשותmetadata אל השרת הראשי, ושולח בקשות

לחתיכות אל שרתי החתיכות )קצת דומה לשרתי שיתוף קבצים( שומרmetadata במטמון, לא שומר dataבמטמון

חוסך בעיות של קונסיסטנטיותמטמון לא מועיל הרבה כאשר קוראים / כותבים פעם-אחת


קריאה של הלקוח הלקוח מבקש מהשרת הראשי לקרוא )שם קובץ, אינדקס

חתיכה(השרת הראשי משיב עם מזהה חתיכה, מיקומי החתיכה "הלקוח מבקש את החתיכה משרת החתיכות "הקרוב ביותר

אשר מחזיק אותה נקבע על-פי כתובת הIP

שרת החתיכות שולח את החתיכה


1כתיבה של לקוח לכל חתיכה יש שרת

חתיכות אחראי מקבלlease מהשרת

הראשי, שצריך לחדש אחרי מעט זמן )דקה(

הקליינט לומד מהשרתהראשי מי העותק האחראי והעותקים המשניים של כל

חתיכה שולח אליהם בקשות )הם

מעבירים אחד לשני בשרשרת(


2כתיבה של לקוח כל העותקים מאשרים את

הכתיבה ללקוח הלקוח שולח בקשת

כתיבה לעותק האחראי השרת האחראי ממספר

את בקשת הכתיבה, ומסדר אותה

השרת האחראי מעביראת הבקשה לשרתים

המשניים השרתים המשניים

מאשרים את ביצוע הכתיבה

השרת הראשי עונה ללקוח


עוד אספקטים מימוש יעיל במיוחד לשרשור )קובץ גדול במיוחד

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

קבצים שינויים בmetadataמבוצעים בשרת הם אטומיים(

הראשי( לשינויים בdata מובטחת אטומיות רק במקרים מיוחדים

loggingלגיבוי השרת הראשי


GFSסיכום :

הצלחה: גוגל משתמשת בו לחיפוש ולאפליקציות נוספותזמינות ושרידות על חומרה זולה( תפוקה טובה, בזכות ההפרדה בין בקרהmetadata )

(dataובין מידע )"בו-זמנית תמיכה בכמויות מידע עצומות ו"הדבקה רעיונות דומים במערכת הקבציםHadoop)שהיא קוד פתוח(

)התנהגות לא-שקופה לאפליקציות )סמנטיקה לא-נקייהביצועים לא טובים לחלק מהאפליקציות

,למשל, אם חוזרים וקוראים או כותבים מאותן כתובותבגלל שאין מטמון אצל הלקוח


וירטואליזציה


מבוא "מערכת ההפעלה מספקת אשליה של "מכונה וירטואלית

לתהליכיםזיכרון וירטואלי השייך כולו לתהליךמעבד וירטואלי" שבו רצים רק חוטי התהליך"ערוצי תקשורת ל"מכונות וירטואליות" אחרות

..אבל:אין בידוד מלא בין תהליכים

ניתן ללמוד על תהליכים וחוטים אחרים דרך קריאות מערכתהמשאבים משותפים - בד"כ אין הקצאה קשיחה של משאבים לתהליכים פירצת אבטחה במערכת ההפעלה יכולה להזיק להרבה תהליכים

קשה לפתח תוכנה "רגישה" כגון מנהלי התקנים ועדכונים לגרעין מ"התלות בחומרה מדור מסוים, בקונפיגורציה מסוימת


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

..עדיין לא מבטל את התלות בחומרה

(data silos )לממגורות מידעמביא )בזבוז רב של יכולות חומרה )חישוב, אחסון, ק/פ

קשה לשתף ביעילות משאבים בין מכונות נפרדות

...עלות גבוהה של ניהול: התקנת כל מכונה, קישוריות, תחזוקה


וירטואליזציה מערכת הפעלה,אפליקציה/שירות[מפרידים בין הזוג[

לבין החומרה..ממתגים שירותים דלילים על חומרה משותפת.מעבירים ממכונה למכונה לפי הצורך מערכת הפעלה,אפליקציה/שירות[מתקינים זוגות[

לפי הצורך.שירותים חדשיםבדיקת שדרוגים ושינוייםשימושים ניסיוניים


Virtual Machine Monitor (VMM)

Non-virtual Machine

( שכבת שכבת תוכנהבין מערכת (הוירטואליזציה

ההפעלה לחומרה נקראת גםhypervisor מדמה חומרה "אמיתית" כלפי מערכת

ההפעלה )התקנים, רגיסטרים, קלט / פלט...(

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

מערכת ההפעלה "חושבת" שהיארצה על חומרה אמיתית

למעשה רצה על מכונה וירטואלית(virtual machine)


Virtual Machine Monitor (VMM)

( שכבת שכבת תוכנהבין מערכת (הוירטואליזציה

ההפעלה לחומרה נקראת גםhypervisor מדמה חומרה "אמיתית" כלפי מערכת

ההפעלה )התקנים, רגיסטרים, קלט / פלט...(

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

מערכת ההפעלה "חושבת" שהיארצה על חומרה אמיתית

למעשה רצה על מכונה וירטואלית(virtual machine)

Virtual Machine


סוגי מכונות וירטואליות

Applications

OS

Hardware

Guest Apps

Hardware

Guest OS

VMM

Hardware

Host OS

VMM

Guest OS

Guest Apps

Native virtualizationUser-mode virtualizationמערכת הפעלה מסורתית


טרמינולוגיה

Hardware

Host OS

VMM

Guest OS

Guest Apps

User-mode virtualization

מארחת מערכת הפעלהרצה על החומרה

יחד עם הVMM מדמה את הסביבה עבור...

האורחתמערכת ההפעלה ,אשר רצה על הסביבה

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


האתגר קשה להבטיח למערכת ההפעלה האורחת העתק זהה

למכונה המדומה:טבלאות דפים ופסיקות דף לדוגמה

אם למע"ה האורחת יש טבלאות דפים משלה, אז הVMM צריךלהעתיק טבלאות אלהלעקוב אחרי פניות ועדכונים לטבלאות ולסמלץ אותם

( כשיש פסיקת דףpage fault) הVMMצריך להחליט אם היא שייכת למע"ה האורחת או לו אם שייך למע"ה האורחת צריץ לסמלץ את פסיקת הדף עבורה

באופן דומה, הVMM צריך לתפוס ולסמלץ כל פעולת (privilegedמכונה מוגנת )


לא תמיד אפשרי יש אספקטים של החומרה שאינם ניתנים

לוירטואליזציהרגיסטרים מסוימים שאינם חשופיםהתקנים מיוחדיםשעונים, והתנהגות זמן-אמת

נפתרים על-ידי כלים וdriversבמע"ה האורחת VMware Tools


סוגים של וירטואליזציה) וירטואליזציה מלאהFull Virtualization(

שקיפות - יכולה להריץ מ"ה ללא שינוי( ניתן לשפר ביצועים בסיוע החומרהAMD-V, Intel VT) VMware, QEMU, Xen

פארא-וירטואליזציה)Para-Virtualization(-מערכת ההפעלה האורחת מודעת לVMM)באמצעות מנהלי ההתקנים( מאפשר שיפור ניכר בביצועים על חשבון השקיפותXen, Z/VM

) מבוסס מערכת הפעלהOS-Level Virtualization(( "כל תהליך או קבוצת תהליכים רצים בתוך "מיכלContainer שמתנהג כמו )

מחשב נפרד לכל דבר )קונפיגורציה נפרדת, רשת, מערכת קבצים(שיתוף הגרעין וניהול המשאבים בין המיכליםשיפור נוסף בביצועים, תלות נוספת בתאימותSolaris Containers, Virtuozzo Containers, POWER WPARs


יתרונות וחסרונות..כמו במכונות ייעודיות

בידוד מלא בין יישומים-נאכפת ע"י ה( הקצאה קשיחה של משאביםVMM)אפשר לפתח ולדבג קוד גרעין בלי לחשוש מתקלות

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

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

+ מספר מערכות הפעלה(VMMתהליכים )ומשמשים עבור ה


דוגמאות בולטותVMWare

מאפשר לכמה מערכות הפעלה קלאסיות לרוץ מעל אותה חומרהXen

קוד פתוח מערכת ההפעלה האורחת מותאמת לVMM נתמך על מעבדיIntel, AMD

Java virtual machine החומרה שמדומה על-ידי הVMMאינה חומרה קיימת

השוואה:http://en.wikipedia.org/wiki/Comparison_of_virtual_machines_features


לדוגמה


סיכום הקורס


תפקידי מערכת הפעלהמערכת ההפעלה מספקת אבסטרקציות

הגדרת האבסטרקציה על-ידי ממשקים אחידיםמימוש האבסטרקציה מעל חומרה והתקנים פיזיים שונים

מערכת ההפעלה מנהלת משאבים


מה היה לנו? תהליכים וחוטים תהליך

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

.יצירת תהליכים וניהולם במערכת ההפעלה.החלפת הקשר

זימון תהליכים.שיטות בסיסיות.שימוש בעדיפויות וריבוי תורים

חוטים


מה היה לנו? תהליכים וחוטים תיאום בין תהליכים וחוטים

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

SignalsPipes לא( כמו קבצים אבל גישה סדרתית בלבד – random)Socketsגם בין תהליכים במחשבים שונים – )'תקשורת דרך זיכרון משותף – בעזרת כלי סנכרון )סמפורים וכו


מה היה לנו? זיכרון.ניהול הזיכרון

swapping. זיכרון וירטואלי - לכל תהליך מרחב כתובות וירטואלי

כל תהליך מרגיש שהוא לבד בעולם והזכרון היחיד הקיים הוא מרחבהכתובות שלו

טבלת הדפים והTLB.

,אלגוריתמים לדפדוף: חמדןFIFO, LRU...קירובים ,


מה היה לנו?קבצים, התקנים ונושאים נוספים

:מערכת הקבציםממשק המשתמש, קבצים, מדריכים לניהול נתונים נוח יותר:מימוש

.מיפוי קבצים לדיסק.ניהול הבלוקים הפנויים.אמינות והתאוששות

מערכות קבצים מבוזרות

תמיכה בארכיטקטורות שרת-לקוחטיפול בפסיקותוירטואליזציה


מדדי הצלחה הצלחת הפתרון תלויה במדד לו רוצים לבצע

אופטימיזציה tradeoffבין מדדים

-למשל בscheduling זמן שהיה ממוצע :(SJF,SRT) לעומת תקורה של החלפות הקשר והרעבה

בלוקים/דפים גדולים גורמים לפרגמנטציה )בזבוזמשאבים(, בלוקים קטנים גורמים לטבלאות גדולות

I/Oומפחיתים יעילות inodeגישה מהירה לקבצים קטנים דרך מצביעים ישירים :


Workloadתכנון תלוי workloadאפיון המשימות שהמערכת צריכה לבצע =

-עקרון הlocality ניבוי העתיד בעזרת העבר – )מבוסס על ההנחה שהעתיד יהיה כמו העבר(

החלפת דפים, חישובworking set ניהולbuffer cache, LRU קביעת עדיפויות לפי אורךCPU burstקביעת גודל דף / בלוק לפי סטטיסטיקות גודל קבצים-הנחה שdeadlock)לא יקרה )גילוי ולא מניעה


הקצאת משאבים ע"י חלוקההקצאה רציפה - גורמת לבעיות

CPUתהליך אחד לא נותן לאחרים לרוץ – פרגמנטציה)חוסר גמישות )קשה לתת לתהליך / קובץ לגדולהקצאה ע"י חלוקה ל"חתיכות" קטנות

-קוונטים של זמן לתזמון בCPUדפים ומסגרות בניהול זיכרוןבלוקים בניהול קבצים ודיסקיםpacketsבתקשורת ניתן לתקן הקצאת משאבים עם הזמן

למשל להוריד עדיפות


כללי אצבע לשיפור ביצועיםשימוש במטמון

HW cache, TLB, Buffer cache, dentry cache…קבצים פתוחים

)עבודה עם חוצצים )והעברת בלוקים של מידע( מאגר של חוטיםthread pool)הימנעות מקריאות מערכת הפעלהתוכניות עם מקומיות גבוהה


על חשיבות המיקבול חוקMoore

-הכפלת מספר הטרנזיזטורים ומהירות הCPU שנים1.5-2 כל חוק דומה קיים גם לגבי נפח דיסקים ורוחב פס של רשתות תקשורת

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

לכן, הדרך היחידה להגדיל את המהירות )התיאורטית( היא ע"י מקבול ריבוי יחידות חישוב(multi-core)-בתוך ה CPU

-מצד שני, ללא ריבוי חוטים, הcoresהללו לא יעשו כלום העתיד טמון בתוכניות מרובות חוטים

אבל צריך להשתמש במנגנוני סנכרון ומודלי תכנות נכוניםמעט מידי סינכרון =< קוד שגוי ובאגים שקשה מאוד לגלותעודף סינכרון =< חוסר מקביליות מודלTransactional Memory


קורסי המשך בפקולטהמערכות קבציםמסדי נתוניםמקבילי ומבוזר

תכנות מקבילי ומבוזרמערכות מבוזרות'אלגוריתמים מבוזרים ב עקרונות של מערכות מבוזרות

אמינות )בהנדסת חשמל(

ארכיטקטורהמבנה מחשבים ספרתיים

תכנון וניתוח מערכות תוכנהמבוא להנדסת תוכנה( תכנות מונחה עצמיםOOP)

תקשורתמבוא לרשתות מחשביםתקשורת באינטרנט


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

או שנלמד במסגרת תרגילי הבית.


בהצלחה!

Documents

Os Technion