הבית > תערוכה > תוכן

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

Mar 08, 2019

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


מיסוך / ביטול זמני של הפרעות

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


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


מוטקס

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


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


ב היפוך עדיפות משימה בעדיפות גבוהה מחכה כי משימה בעדיפות נמוכה יש mutex, אבל את המשימה בעדיפות נמוכה לא ניתנת זמן CPU כדי לסיים את עבודתה. פתרון אופייני הוא לקבל את המשימה שבבעלותה מוטקס ב, או 'לרשת', את העדיפות של המשימה המתנה הגבוהה ביותר. אבל גישה פשוטה זו נעשית מורכבת יותר כאשר יש רמות רבות של המתנה: משימה מחכה למוטקס הנעולה במשימה B, המחכה למוטקס הנעול במשימה. ג. טיפול במספר רמות של ירושה גורם לקוד אחר לפעול בהקשר עדיפות גבוהה ובכך יכול לגרום רעב של הנושאים בעדיפות בינונית.


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


הודעה עוברת

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