מאת: Chris Main TenAsys Corporation. עם הפיכת מעבדים מרובי ליבות לאופציה זמינה וזולה, עולות שאלות חדשות בהקשר של ניצול היכולות החדשות הללו.
המאמר מתרכז במעבדים ממשפחת X86 ובשימושים שלהם למערכות זמן אמת. המאמר מתאר דרך לתקשורת בין תהליכים שמופעלים מעל מע”ה לזמן אמת שונות שרצות כל אחת מעל ליבה שונה. הדרך מאפשרת שמירה על יכולות זמן אמת – ובו בזמן העלאה משמעותית בביצועים. הטכנולוגיה המתוארת במאמר היא אחד מהפיתוחים החדשים במערכת ההפעלה INtime שמפותחת ומסופקת על ידי חברת TenAsys מזה 15 שנה.
איור 1
איור 2
המרת מערכות Embedded שבנוית מכמה פלטפורמות מחשוב – לפלטפורמה אחת.
מערכת משובצת מחשב (Embedded System) כוללת בדרך כלל מספר פונקציות שמתקשרות האחת עם השניה כדי לבצע משימה. המשימות עשויות לכלול אלמנטי בקרה, איסוף נתונים, ולעיתים ממשק מפעיל. לעיתים המשימות הללו מבוזרות בין מחשבים שונים המחוברים ביניהם ברשת תקשורת. בזכות הגדלה משמעותית בביצועי מחשבי PC, יכולים OEMs לשלב פונקציות שבעבר חולקו בין כמה מחשבים לתוך מחשב אחד. בכך הם יכולים לשפר את אמינות ויעילות המערכות, ולהחליף מרכיבי חומרה יעודיים מהעבר, למרכיבי תוכנה.
מאידך, בשינוי המימוש קיימים אתגרים שצריך להתיחס אליהם, וצריך לשמר את היתרונות של הפרדת הפונקציות לפלטפורמות שונות.
היתרון הברור של ההפרדה הוא יכולת התגובה המהירה והקצובה בזמן לארועים הקרויה דטרמיניסטיות. מערכות משובצות דורשות כמעט תמיד תכונה זו כדי לבצע את מטלותיה באמינות ובצורה סטבילית – היכולת לבצע תמיד את הנדרש בסדר קבוע. ההעברה לפלטפורמה אחת מחייבת תקשורת יעילה מבחינת משך הזמן שהיא דורשת – בין חלקי המערכת השונים הממומשים על אותו ה-PC.
איור 3
איור 4
איור 5
אפשרות אחת היא לממש כל פונקציה שרצה קודם לכן על פלטפורמה נפרדת כ-Process מעל מע”ה לזמן אמת. פונקציות התזמון – Scheduling המשותפות לכל ה-Processes עלולים לגרום לתלות בין ה-Processes כך ש-Process שנהנה בעבר מעדיפות בריצתו בפלטפורמה הנפרדת עלול לאבד את הדטרמיניסטיות שלו.
גם פיתרון וירטואליזציה כדרך לבצע קונסוליזציה עלול להכשל כיון שהוא משולב בתכנון בשלב מאוחר.
הכלל הברור הוא: דטרמיניסטיות ויכולת גידול (סקלביליות) חיבים להלקח בחשבון מהשלבים הראשונים בתכנון.
הגדרת הדרישות
מערכת בקרה מאופינת על ידי בלוקים פונקציונליים FB, כל אחד מהם מבצע משימה ספציפית ומקושר להתקן I/O כמו מנוע, מצלמה וכו’. כל FB עשוי להיות מקושר ל-FB אחרים.
דוגמה למערכת כזו מתוארת באיור 1. FB2 הוא PLC Programmable Logic
() ו-FB3 הוא התקן שמצלם וידאו מנתח אותו ומודיע ל- PLC בתוצאה Go/NoGo. הוא מנוע שמקבל הוראה להציג את האוביקט הבא לצילום.
עם עליית הזמינות של ביצועי מחשוב חזקים, אפשר להעביר חלק או את כל הפונקציות לפלטפורמת חומרה אחת. היתרון המושג הוא חיבור יעיל יותר בין פונקציות, דבר המוביל לביצועים טובים יותר, אמינות מערכת כוללת גבוהה יותר ולרב גם עלות מופחתת. אבל איחוד הפונקציות מחייב הוספת מערכת ניהול, משום שיש לקבוע את אופן חלוקת המשאבים המשותפים כגון זיכרון וקלט/פלט שמוקצים לכל FB.
איור 6
פתרון באמצעות
מעבד יחיד
דרך מקובלת לשלב פונקציות על PC אחד היא ליישם כל Function Block כתהליך נפרד שפועל מעל מע”ה לזמן אמת. למ”ה כזו יש פונקציות מובנות – כמו תזמון מטיפוס Preemptive. המשמעות היא שמופסקת ריצה עבור FB אחד באם מתעורר תהליך חדש לטובת FB אחר, שמוגדר כבעל עדיפות גבוהה יותר.
זהו פתרון פשוט יחסית. הוא מתואר באיור 2. הפתרון נשען על
IPC – Inter Process Communication, שהינה חלק סטנדרטי מכל מע”ה לזמן אמת.
החסרון בגישה זו הוא שהמשאבים שעומדים לרשות כל FB אינם מופרדים. עלול להווצר מצב שפעילות I/O רבה ששיכת ל-FB מסוים תשפיע משמעותית על ריצה של FB אחר. ניתן לשפר
את המצב על ידי כיוונון התהליכים מבחינת העדיפות והמשאבים שלהם. אולם צריך לעבור כוונון כזה שוב ברגע שמשנים חומרה, מוסיפים FB נוסף או שרוצים לשפר FB מסוים.
פתרונות לריבוי ליבות
מעבדים מרובי ליבות נכנסים בשנים האחרונות לשימוש נרחב. מאידך – בשוק ה-Embedded ליישומי בקרה, ההתפתחות הזו עדיין לא מורגשת. הסיבה היא שיצרנים בשוק הזה לא החליטו עדיין איך להסב את המוצרים הקודמים שלהם שבנויים על מחשב אחד, למחשב רב ליבות כיון שלא הוגדר נתיב מקובל של הסבה כזו שיספק שיפורים במינימום שינויי תכנה.
במאמץ לספק פתרון הוצגו מערכות ניהול שבעיקרן הן מע”ה עם Load Schedulers. המערכת השכיחה היא SMP – Symmetrical MultiProcessing. שיטה זו קבילה בהחלט במערכות שאינן לזמן אמת. אולם עבור מערכות הפועלות בזמן אמת שיטת SMP אינה קבילה כיון שכל FB וביצועי ה-I/O שלו יושפעו מאד ממה שקורה ב-FB אחר.
גישה טובה יותר היא לבצע וירטואליזציה, כשכל FB רץ על ליבה משלו. לכל ליבה יש מנגנוני תזמון, זכרון, והתקני I/O משלה. זוהי מערכת AMP – Asynchronous Multi Processing שמתוארת באיור 4.
רעיון הוירטואליזציה מגדיר הפרדה נכונה, אבל אינו מספיק. יש להשלים אותו במימוש ההתקשרות בין FBs שרצים על ליבות שונות. תקשורת כזו אפשר להוסיף לשכבת הישום או שתהיה ממומשת בכל מערכת הפעלה של כל ליבה.
הוספת התקשורת ליישום קלה למימוש אבל קשה להפוך אותה לשקופה מבחינת המפתח. קשה עוד יותר לשלב אותה בניהול העדיפויות של משימות אחרות.
הגישה הטובה יתר היא לשלב את ה-IPCכחלק ממערכת ההפעלה ולשלב אותה בתוך מערכת ניהול העדיפויות. זה מאפשר למתכנת להתיחס לאוביקטים רגילים כמו Mailboxes Semaphores ו-Shared Memory Blocks כדי לממש את ה-IPC באותו המחשב בין הליבות שלו, ובין המחשבים דרך תקשורת מהירה (LAN). גישה זו מאפשרת לבזר FBs במיגוון קונפיגורציות בשינויי קוד מינימליים איור 5 ממחיש זאת.
כדי לממש מנגנון תקשורת שמשולב בתוך מערכת ניהול העדיפויות, כל FB צריך לדעת את המצב בו נמצא FB (גם זה על ליבה אחרת) שבו הוא תלוי. זה נעשה על ידי שכבת ניהול שמאפשרת “איתותים” כמו יצירה או מחיקה של תהליכים שקשורים ביניהם. גם ה-IPC וגם שכבת הניהול מתוכננים לרוץ כל כל אחת ממע”ה המבוזרות – בין אם זה על אותו ה-PC בין ליבותיו השונות, או בין PCs שמחוברים ב-LAN. כך מתאפשר לבצע Scaling בשמירה על הפונקציונליות ובמינימום שינויי תכנה.
איור 8
איור 9
איך לממש
Global objects
אותם אוביקטים שמאפשרים את התקשורת שתוארה בפרק הקודם קרויים Global Objects והם בעלי התכונות הבאות:
כל ליבה מריצה עותק מלא של מע”ה, שיש לה משאבים משלה: זכרון, מנגנוני תזמון, התקני I/O והפסיקות השייכות להתקנים אלו. תהליך שרץ על ליבה אחת אינו מושפע מ”חבריו” שרצים על
ליבות אחרות.
כל אוביקט ניתן לגישה על ידי Handle.
מנגנון אסינכרוני יעיל של Message Passing מהווה את שכבת ה-Transport בין הליבות.
ממשק המתכנת – API הורחב בצורה שקופה, כדי לאפשר אותו קוד תקשורת שמתנהל בין תהליכים על אותה הליבה, להתנהל בין ליבות. בכל ליבה רץ Global Object Process שמשמש כ-Agent לבקשות פניה לאוביקטים שלו, שמגיעים מליבות אחרות.
שכבת שרות הניהול הקרויה DSM (איור 6) מאפשרת ל-Process לרשום את התלות שלו ב-Process שרץ על ליבה אחרת, כך שיקבל איתות על נפילה או סיום שלו. בנוסף שכבת ניהול זו מודיעה לליבות על shutdown או תקלה בליבות אחרות.
בדוגמא הבאה שמציגה את המימוש של המערכת שתוארה לעיל הוספנו גם את Windows, והתפיסה של ה-IPC וה-DSM הורחבה גם עבורו.
בהמשך לדוגמא שהוצגה בתחילת המאמר באיור 1, יישום מצלמת הוידאו (נקרא לו FB3) רץ על Process C בליבה 3, וישום ה-PLC () רץ על Process B בליבה 2. כמו קודם ישום המצלמה צריך להודיע ל-PLC על גמר הקליטה והניתוח של הוידאו והאם התהליכים הללו הסתיימו בהצלחה או לא. אם התהליכים היו רצים על אותו ליבה היה פשוט לתקשר ביניהם בשימוש ב-Mailbox כשעובדים ב-Global objects אותו מכניזם עובד -בתוספת של 2 צעדי תכנות:
שלב א: Process B שמבצע את ה-PLC – צריך לגרום ל-Mailbox שאצלו להפוך לגלובלי כדי שתהליכים שרצים על ליבות אחות יוכלו לתקשר איתו.
שלב ב: שתי פקודות נוספות צריכות להתבצע כדי ש-Process C יוכל למצוא Global Objects (במקרה הזה Mailbox) לצורך של כתיבה אליו.
טבלה 1 מתארת את התוספת שיש לבצע בשני התהליכים.
בפעולות שצוינו, ה-DSM רושם את החיבור בין התהליכים ברגע יצירת
ה-Mailbox. כך שאם Process B שהינו תהליך ה-PLC הופך לתקול, Process C שהינו תהליך הוידאו יקבל איתות על כך ויגיב בצורה המתאימה ליישום.
כמו ה-Mailbox כן גם אוביקטים של זכרון משותף גלובליים (Shared Memory Object Global) משמשים לקישור מידע בין ליבות. הם מתאימים למצבים בו כמות המידע לקישור היא גדולה או גדולה מאד.
אוביקטים של זכרון משותף צריכים בדרך כלל לשמר קשר בין יותר משני תהליכים (שרצים על ליבות שונות), נדרש שהאוביקט יהיה “חי” גם אם
ה-Process שיצר אותו כבר עצר, או כבר לא נזקק לאובייקט. המכניזם משתמש באינדקס. למשל אם ניתנת גישה לארבעה תהליכים, ניתן לאובייקט אינדקס בערך 4. כל פעם שתהליך מבצע הסרת מינוי (unsubscribe) האינדקס יורד ב-1. רק בפעולת ה-unsubscribe האחרונה – יוסר האובייקט.
פתרון ה-Global Object מורחב גם
ל-Windows. בדוגמא הראשונה (איור 1) יישום ב-Windows יכול לקרוא וידאו ישירות מ-Memory Object שאליו כתב יישום שרץ מעל מע”ה לזמן אמת שיצרה ומנהלת את האוביקט.
שיקולי תכנון
כאשר Process מעל מע”ה לז”א אחת מתקשר לאוביקט שנמצא במע”ה שניה חייבת ההתנהגות של שתי מע”ה להיות צפויה מבחינת סדר פעולות ועמידה בזמנים, וה-overhead לטיפול חייב להיות מינימלי. נוסף לכך התכונות הבסיסיות של Task Priroty והמימוש של טיפול
ב-Priority Inversion חייבים להשמר.
ה-overhead הוא מינימלי וה-predictability מקסימלי תודות לשימוש ב-Shared Memory שנעזר ב-InterProcessor Interrupt בשכבת Messae Passing Transport.
בצד המקבל מותקן agent שפועל עבור
ה-sending Thread והוא כול שתי קבוצות פעולה. האחת כוללת יצירה מחיקה ו”איתות” (signaling) שמבוצעים ע”י ה-agent בצורה ישירה, והקבוצה השניה כוללת את אלה שמחכים לאוביקט. קבוצה זו מטופלת על ידי Proxy Thread שרץ בעדיפות של ה-Thread הקורא. כך מושג שה-Thread הקורא מתנהל לפי שיקולי מננוני התזמון של מע”ה בה מוגדר האוביקט.
לדוגמא ניקח שני תהליכים, שכ”א מהם מממש FB על ליבה אחת (מוצג באיור 7) ומימוש שני של אותו הישום על שתי ליבות (איור 8).
Process A מכיל אוביקט ש”עליו” מחכה Thread שרץ ב-Process B. כשנשלח איתות לאוביקט, ה-Thread נכנס לרשימת “המוכנים לריצה” (Ready List) וירוץ כשיהיה ב-priority הגבוה ברשימה.
מקרה דומה מוצג באיור 8 בהבדל משמעותי אחד: הפתרון הוא של שתי ליבות. כאשר שולחים לאוביקט, ה-Proxy Thread הופך ל-Ready. לכשיגיע לראש רשימת ה-Ready הוא ירוץ וישלים את המשימה עבור ה-Thread שב-Process B.
מצב זה מבטיח מימוש נכון של מנגנון העדיפויות גם כשממירים את התכנון לכמה ליבות.
שיקולי ביצועים
להשגת overhead נמוך מומלץ להשתמש באוביקט זכרון. אוביקט כזה ניתן למפות לתהליכים שפועלים על ליבות אחרות, כפי שניתן למפות בתהליכים שרצים על ליבה אחת. לאחר פעולת המיפוי אין overhead נוסף. את הגישה לזכרון ניתן לנהל למשל על ידי Semaphore שלכל התהליכים יש גישה אליו. כך מושג תיאום בין כל ה-FBs על כל הליבות.
לסיכום
התכנון שהוצג מאפשר העזרות בריבוי ליבות במערכות Embedded מבלי להקריב את התכונות החשובות לזמן אמת: דטרמיניסטיות (היכולת להבטיח תגובה בזמן קצר) וסטביליות (היכולת להבטיח סדר פעולות קבוע).
מע”ה INtime שמנצלת את הטכנולוגיה שהוצגה מגדילה את יכולת הביצועים האפשרית בהרצת הליבות במקביל על משימות שונות, תוך כדי שמירה על הדטרמיניסטיות והסטביליות.
יכולות אלו מאפשרות Scaling (יכולת גידול) בשינויי תוכנה מינימליים.
מחבר המאמר Chris Maim הוא אחד מהמייסדים של TenAsys.
Chris היה בצוות שהחל את פיתוח מוצר הדגל של החברה, INtime וממשיך עד היום בתפקיד זה במסגרת תפקידו כ-CTO של החברה.
ניתן לקרוא חומר נוסף על מוצר INtime ומוצרים אחרים באתר חברת TenAsys. החברה מיוצגת בישראל ומוצריה נמכרים בה מזה 7 שנים.
