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

יחסי יצרן - צרכן

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

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

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

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

בפועל נשתמש לשם כך בסמפורים:

החלק התחתון מייצר ומסמן ב- signal. החלק העליון צורך ומסמן ב- wait.

דגש

signal מותרת מתוך פסיקה.  wait לא! (כי יתכן אז מצב שנוציא את NULLPROC מתור ה-ready).

תור בקשות

ב- driver-ים צריך ליישם לעתים תורי בקשות.

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

במקרה של ה- tty driver הסמפורים מטפלים לנו בתור של המחכים, בעוד הבקשות הן פשוטות:  כתוב תו מסוים או קרא תו. ב- driver של דיסק הבקשות מורכבות יותר: קריאה ממקום מסוים או כתיבה למקום מסוים. אנו צריכים לשמור את הבקשה עצמה עד שנוכל לטפל בה. אין אנו מעוניינים שהסמפורים יטפלו לנו בתור הבקשות, שכן אנו רוצים לבצע אופטימיזציה על הסדר של הבקשות: היות שלוקח זמן ארוך יחסית להעברת הראש ממקום למקום, נרצה שהראש יזוז קודם לבקשה קרובה ואח”כ לרחוקה, כדי לחסוך במרחק שעליו לעבור.

ישום ב- XINU

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