גוגל החלה לפתוח את היישום של מודל הזרימה M:N

גוגל מוּצָע להכללה בליבת לינוקס את הסט הראשון של תיקונים עם הטמעת הרכיבים הדרושים כדי להבטיח את עבודתו של מודל השרשור M:N. היוזמה של גוגל קשורה לפתיחת API שפותח בדלתיים סגורות לעבור ל עבור ליבת לינוקס, המספקת תת-מערכת מרובת הליכי שרשרת המיושמת במרחב המשתמש המשתמשת במודל השרשור M:N. תת-המערכת משמשת את גוגל כדי לספק שירותים הדורשים עיכובים מינימליים. תזמון וניהול הפצת השרשורים מבוצעים כולו במרחב המשתמש, מה שיכול להפחית משמעותית את מספר בוררי ההקשר על ידי מזעור ביצוע קריאות המערכת.

כדי להבטיח את פעולת המשנה הזו, ה- SwitchTo API יושם ברמת ליבת לינוקס, ומציע שלוש פעולות בסיסיות - המתנה, המשך והחלפה (החלפה). להכללה בליבה, מוצע קוד לפעולת FUTEX_SWAP חדשה, משלים FUTEX_WAIT ו-FUTEX_WAKE, ומספקת מסגרת לבניית ספריות מרחבי משתמש מרובי הליכי. ניתן להשתמש ב-FUTEX_SWAP גם להעברת הודעות בין משימות, בדומה ל-RPC. לדוגמה, נכון לעכשיו, כדי להעביר הודעה בין משימות, נדרשות לפחות ארבע שיחות ל-FUTEX_WAIT ול-FUTEX_WAKE, בעוד ששימוש ב-FUTEX_SWAP יאפשר לבצע פעולה אחת מהר יותר פי 5-10.

כיום, מודלים הזרימה 1:1 ו-N:1 משמשים בעיקר בפועל. הדגם 1:1 משמש ב NPTL (שרשורי POSIX) ו LinuxThreads, ומרמז על מיפוי ישיר של שרשור מרחב משתמש לשרשור (יחידת תזמון ביצוע) ברמת הקרנל. מודל N:1 מיושם ב GNU Pth, מביא את תזמון השרשורים למרחב המשתמש ומאפשר ל-N שרשורי מרחב המשתמש להיקשר לשרשור בודד בקרנל, מבלי שהקרנל ידע על שרשורי משתמש.

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

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

מקור: OpenNet.ru