.NET: כלים לעבודה עם ריבוי השחלות וא-סינכרון. חלק 1

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

הצורך לעשות משהו באופן אסינכרוני, מבלי לחכות לתוצאה כאן ועכשיו, או לחלק עבודה גדולה בין מספר יחידות המבצעות אותו, היה קיים לפני הופעת המחשבים. עם הופעתם, הצורך הזה הפך למוחשי מאוד. כעת, בשנת 2019, אני מקליד את המאמר הזה על מחשב נייד עם מעבד Intel Core 8 ליבות, עליו פועלים יותר ממאה תהליכים במקביל, ועוד יותר שרשורים. בקרבת מקום, יש טלפון מעט עלוב, שנקנה לפני כמה שנים, יש לו מעבד 8 ליבות על הסיפון. משאבים נושאיים מלאים במאמרים ובסרטונים שבהם המחברים שלהם מעריצים את סמארטפונים הדגל של השנה הכוללים מעבדים בעלי 16 ליבות. MS Azure מספקת מכונה וירטואלית עם מעבד 20 ליבות ו-128 TB RAM בפחות מ-$2 לשעה. למרבה הצער, אי אפשר לחלץ את המקסימום ולרתום את הכוח הזה מבלי להיות מסוגל לנהל את האינטראקציה של חוטים.

טרמינולוגיה

תהליך - אובייקט מערכת ההפעלה, מרחב כתובות מבודד, מכיל שרשורים.
פְּתִיל - אובייקט OS, יחידת הביצוע הקטנה ביותר, חלק מתהליך, חוטים חולקים ביניהם זיכרון ומשאבים אחרים בתוך תהליך.
ריבוי משימות - מאפיין מערכת ההפעלה, היכולת להפעיל מספר תהליכים בו זמנית
רב ליבות - תכונה של המעבד, היכולת להשתמש במספר ליבות לעיבוד נתונים
ריבוי עיבודים - תכונה של מחשב, היכולת לעבוד בו זמנית עם מספר מעבדים פיזית
ריבוי השרשורים - תכונה של תהליך, היכולת להפיץ עיבוד נתונים בין מספר שרשורים.
מַקבִּילוּת - ביצוע מספר פעולות פיזית בו זמנית ליחידת זמן
אסינכרוניה - ביצוע פעולה ללא המתנה להשלמת עיבוד זה; ניתן לעבד את תוצאת הביצוע מאוחר יותר.

מטאפורה

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

בזמן הכנת ארוחת הבוקר בבוקר אני (CPU) אני בא למטבח (מחשב). יש לי 2 ידיים (ליבות). ישנם מספר מכשירים במטבח (IO): תנור, קומקום, טוסטר, מקרר. אני מדליק את הגז, שם עליו מחבת ויוצק לתוכו שמן בלי לחכות שיתחמם (באופן אסינכרוני, Non-Blocking-IO-Wait), אני מוציא את הביצים מהמקרר ושובר אותן לצלחת, ואז טורף אותן ביד אחת (שרשור מס' 1), והשנייה (שרשור מס' 2) מחזיק את הצלחת (משאב משותף). עכשיו אני רוצה להדליק את הקומקום, אבל אין לי מספיק ידיים (שרשור הרעבה) בזמן הזה המחבת מתחממת (מעבד את התוצאה) אליה אני יוצק את מה שהקצפתי. אני מושיט את ידו אל הקומקום ומדליק אותו ומתבונן בטיפשות במים רותחים בו (חסימה-IO-המתנה), למרות שבזמן הזה הוא יכול היה לשטוף את הצלחת שבה הקציף את החביתה.

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

המשך המטאפורה:

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

כלי NET

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

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

פותח שרשור

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

• ThreadStart - אין פרמטרים
• ParametrizedThreadStart - עם פרמטר אחד מסוג אובייקט.

הנציג יבוצע בשרשור החדש שנוצר לאחר קריאה למתודה Start.אם נציג מסוג ParametrizedThreadStart הועבר לבנאי, אז יש להעביר אובייקט למתודה Start. מנגנון זה נחוץ כדי להעביר כל מידע מקומי לזרם. ראוי לציין שיצירת שרשור היא פעולה יקרה, והשרשור עצמו הוא אובייקט כבד, לפחות בגלל שהוא מקצה 1MB של זיכרון על המחסנית ודורש אינטראקציה עם OS API.

new Thread(...).Start(...);

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

מושג כללי:

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

כדי להשתמש בשרשור מהמאגר, קיימת שיטת QueueUserWorkItem שמקבלת נציג מסוג WaitCallback, שיש לו חתימה זהה ל-ParametrizedThreadStart, והפרמטר המועבר אליו מבצע את אותה פונקציה.

ThreadPool.QueueUserWorkItem(...);

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

ThreadPool.RegisterWaitForSingleObject(...)

ל-.NET יש טיימר שרשור והוא שונה מטיימרים של WinForms/WPF בכך שהמטפל שלו ייקרא על שרשור שנלקח מהמאגר.

System.Threading.Timer

ישנה גם דרך אקזוטית למדי לשלוח נציג לביצוע לשרשור מהבריכה - שיטת BeginInvoke.

DelegateInstance.BeginInvoke

ברצוני להתעכב בקצרה על הפונקציה שאליה ניתן לקרוא לרבות מהשיטות לעיל - CreateThread מ-Kernel32.dll Win32 API. יש דרך, הודות למנגנון של שיטות חיצוניות, לקרוא לפונקציה הזו. ראיתי קריאה כזו רק פעם אחת בדוגמה נוראית של קוד מורשת, והמוטיבציה של המחבר שעשה בדיוק את זה עדיין נותרה בגדר תעלומה עבורי.

Kernel32.dll CreateThread

צפייה וניפוי באגים באשכולות

ניתן להציג את השרשורים שנוצרו על ידך, את כל רכיבי הצד השלישי ומאגר ה-.NET בחלון ה-Threads של Visual Studio. חלון זה יציג מידע על שרשור רק כאשר היישום נמצא תחת ניפוי באגים ובמצב הפסקה. כאן אתה יכול להציג בנוחות את שמות המחסנית ואת סדרי העדיפויות של כל שרשור, ולעבור איתור באגים לשרשור ספציפי. באמצעות המאפיין Priority של המחלקה Thread, ניתן להגדיר את העדיפות של thread, אשר ה-OC וה-CLR יתפסו כהמלצה בעת חלוקת זמן המעבד בין שרשורים.

ספריית מקבילות משימות

ספריית משימות מקבילה (TPL) הוצגה ב-.NET 4.0. עכשיו זה הסטנדרט והכלי העיקרי לעבודה עם אסינכרוניה. כל קוד המשתמש בגישה ישנה יותר נחשב למורשת. היחידה הבסיסית של TPL היא מחלקה Task ממרחב השמות System.Threading.Tasks. משימה היא הפשטה על חוט. עם הגרסה החדשה של שפת C#, קיבלנו דרך אלגנטית לעבוד עם Tasks - אופרטורים אסינכרוניים/ממתינים. המושגים הללו אפשרו לכתוב קוד אסינכרוני כאילו הוא פשוט וסינכרוני, זה אפשר אפילו לאנשים עם הבנה מועטה של ​​פעולתם הפנימית של שרשורים לכתוב אפליקציות שמשתמשות בהם, אפליקציות שלא קופאות בעת ביצוע פעולות ארוכות. השימוש ב-async/wait הוא נושא למאמר אחד או אפילו לכמה מאמרים, אבל אנסה להבין את עיקרו בכמה משפטים:

• async הוא משנה של שיטה המחזירה Task או void
• and await הוא מפעיל לא חוסם משימה מחכה.

שוב: מפעיל ההמתנה, במקרה הכללי (יש חריגים), ישחרר את שרשור הביצוע הנוכחי, וכאשר המשימה תסיים את ביצועה, ואת השרשור (למעשה, נכון יותר לומר את ההקשר , אך על כך בהמשך) ימשיך בביצוע השיטה. בתוך NET, מנגנון זה מיושם באותו אופן כמו החזרת תשואה, כאשר השיטה הכתובה הופכת למחלקה שלמה, שהיא מכונת מצבים וניתנת לביצוע בחלקים נפרדים בהתאם למצבים אלו. כל מי שמעוניין יכול לכתוב כל קוד פשוט באמצעות asynс/await, קומפילציה והצגה של המכלול באמצעות JetBrains dotPeek עם קוד מהדר מופעל.

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

using TCO = System.Threading.Tasks.TaskCreationOptions;

public static async void VoidAsyncMethod() {
    var cancellationSource = new CancellationTokenSource();

    await Task.Factory.StartNew(
        // Code of action will be executed on other context
        () => Thread.Sleep(10000),
        cancellationSource.Token,
        TCO.LongRunning | TCO.AttachedToParent | TCO.PreferFairness,
        scheduler
    );

    //  Code after await will be executed on captured context
}

נוצרת משימה עם מספר אפשרויות:

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

הפרמטר השני המועבר לשיטה הוא CancellationToken. כדי לטפל בצורה נכונה בביטול פעולה לאחר תחילתה, יש למלא את הקוד המבוצע בצ'קים למצב CancellationToken. אם אין בדיקות, אזי שיטת הביטול הנקראת לאובייקט CancellationTokenSource תוכל לעצור את ביצוע המשימה רק לפני שהיא מתחילה.

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

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

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

במשימה ששיטת StartNew החזירה, כמו גם בכל אחת אחרת, אתה יכול לקרוא למתודה ConfigureAwait עם הפרמטר false, ואז הביצוע אחרי await ימשיך לא בהקשר שנלכד, אלא על קונטקסט שרירותי. יש לעשות זאת תמיד כאשר הקשר הביצוע אינו חשוב עבור הקוד לאחר ההמתנה. זוהי גם המלצה של MS בעת כתיבת קוד שיימסר ארוז בספרייה.

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

public static async void AnotherMethod() {

    int result = await AsyncMethod(); // good

    result = AsyncMethod().Result; // bad

    AsyncMethod().Wait(); // bad

    IEnumerable<Task> tasks = new Task[] {
        AsyncMethod(), OtherAsyncMethod()
    };

    await Task.WhenAll(tasks); // good
    await Task.WhenAny(tasks); // good

    Task.WaitAll(tasks.ToArray()); // bad
}

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

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

חיסרון נוסף של גישה זו הוא טיפול בשגיאות מסובך. העובדה היא שקל מאוד לטפל בשגיאות בקוד אסינכרוני בעת שימוש ב-async/wait - הן מתנהגות אותו דבר כאילו הקוד היה סינכרוני. בעוד שאם נחיל גירוש שדים סינכרוני על משימה, החריג המקורי הופך ל-AggregateException, כלומר. כדי להתמודד עם החריגה, תצטרכו לבחון את סוג InnerException ולכתוב אם לשרשר את עצמכם בתוך בלוק catch אחד או להשתמש ב-catch when construct, במקום בשרשרת בלוקי ה-catch המוכרת יותר בעולם C#.

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

השיטות WhenAny ו-WhenAll נוחות במיוחד להמתנה לקבוצת משימות; הן עוטפות קבוצת משימות לאחד, אשר יופעל או כאשר משימה מהקבוצה תופעל לראשונה, או כאשר כולן השלימו את הביצוע שלהן.

עצירת שרשורים

מסיבות שונות, ייתכן שיהיה צורך להפסיק את הזרימה לאחר תחילתה. ישנן מספר דרכים לעשות זאת. למחלקה Thread יש שתי שיטות בעלות שם מתאים: הפלה и להפריע. הראשון מאוד לא מומלץ לשימוש, כי לאחר התקשרות אליו בכל רגע אקראי, במהלך עיבוד של כל הוראה, תיזרק חריגה ThreadAbortedException. אתה לא מצפה שיוצא חריג כזה כשמגדילים כל משתנה מספר שלם, נכון? וכאשר משתמשים בשיטה זו, זהו מצב מאוד אמיתי. אם אתה צריך למנוע מה-CLR ליצור חריג כזה בקטע מסוים של קוד, אתה יכול לעטוף אותו בשיחות Thread.BeginCriticalRegion, Thread.EndCriticalRegion. כל קוד שנכתב בבלוק סופית עטוף בקריאות כאלה. מסיבה זו, במעמקי קוד המסגרת ניתן למצוא בלוקים עם ניסיון ריק, אך לא ריק לבסוף. מיקרוסופט לא מעודדת שיטה זו עד כדי כך שהם לא כללו אותה בליבת .net.

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

שתי האפשרויות שתוארו לעיל הן גרועות בגלל חוסר הניבוי שלהן. הפתרון הוא להשתמש במבנה CancellationToken וכיתה CancellationTokenSource. הנקודה היא כזו: נוצר מופע של המחלקה CancellationTokenSource ורק מי שבבעלותו יכול לעצור את הפעולה על ידי קריאה למתודה ביטול. רק ה-CancelationToken מועבר לפעולה עצמה. בעלי CancellationToken אינם יכולים לבטל את הפעולה בעצמם, אלא יכולים רק לבדוק אם הפעולה בוטלה. יש תכונה בוליאנית עבור זה IsCancelationRequested ושיטה ThrowIfCancelRequested. האחרון יזרוק חריג TaskCancelledException אם השיטה Cancel נקראה במופע של CancellationToken שהולך לתוכי. וזו השיטה שאני ממליץ להשתמש בה. זהו שיפור ביחס לאפשרויות הקודמות על ידי השגת שליטה מלאה באיזו נקודה ניתן לבטל פעולת חריגה.

האפשרות האכזרית ביותר לעצירת שרשור היא לקרוא לפונקציה של Win32 API TerminateThread. התנהגות ה-CLR לאחר קריאה לפונקציה זו עשויה להיות בלתי צפויה. ב-MSDN נכתב על הפונקציה הזו: "TerminateThread היא פונקציה מסוכנת שיש להשתמש בה רק במקרים הקיצוניים ביותר. "

המרת API מדור קודם ל-Task Based בשיטת FromAsync

אם יתמזל מזלך לעבוד על פרויקט שהתחיל לאחר הצגת משימות והפסיק לגרום אימה שקטה עבור רוב המפתחים, אז לא תצטרך להתמודד עם הרבה ממשקי API ישנים, הן של צד שלישי והן אלה של הצוות שלך. עונה בעבר. למזלנו, צוות .NET Framework דאג לנו, אם כי אולי המטרה הייתה לדאוג לעצמנו. כך או כך, ל-.NET יש מספר כלים להמרת קוד ללא כאב שנכתב בגישות תכנות אסינכרוניות ישנות לזו החדשה. אחת מהן היא שיטת FromAsync של TaskFactory. בדוגמה של הקוד למטה, אני עוטף את שיטות האסינכרון הישנות של המחלקה WebRequest ב-Task באמצעות שיטה זו.

object state = null;
WebRequest wr = WebRequest.CreateHttp("http://github.com");
await Task.Factory.FromAsync(
    wr.BeginGetResponse,
    we.EndGetResponse
);

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

המר API מדור קודם ל-Task Based באמצעות מחלקה TaskCompletionSource

כלי חשוב נוסף שיש לקחת בחשבון הוא הכיתה TaskCompletionSource. מבחינת פונקציות, מטרה ועיקרון הפעולה, זה אולי מזכיר קצת את שיטת RegisterWaitForSingleObject של המחלקה ThreadPool, עליה כתבתי למעלה. באמצעות מחלקה זו, אתה יכול בקלות ובנוחות לעטוף ממשקי API אסינכרוניים ישנים ב-Tasks.

אתה תגיד שכבר דיברתי על שיטת FromAsync של המחלקה TaskFactory המיועדת למטרות אלו. כאן נצטרך לזכור את כל ההיסטוריה של הפיתוח של מודלים אסינכרוניים ב-.net שהציעה מיקרוסופט במהלך 15 השנים האחרונות: לפני ה-TAP (TAP), היה ה-Asynchronous Programming Pattern (APP), אשר היה על שיטות להתחילDoSomething חוזר IAsyncResult ושיטות סוֹףDoSomething שמקבל את זה ועבור מורשת השנים הללו שיטת FromAsync היא פשוט מושלמת, אבל עם הזמן, היא הוחלפה ב-Event Based Asynchronous Pattern (EAP), אשר הניח כי אירוע יועלה כאשר הפעולה הא-סינכרונית תושלם.

TaskCompletionSource מושלם עבור גלישת משימות וממשקי API מדור קודם שנבנו סביב מודל האירוע. המהות של עבודתו היא כדלקמן: לאובייקט ממחלקה זו יש מאפיין ציבורי מסוג Task, שניתן לשלוט במצבו באמצעות שיטות SetResult, SetException וכו' של המחלקה TaskCompletionSource. במקומות שבהם אופרטור ההמתנה הוחל על משימה זו, הוא יבוצע או ייכשל עם חריגה בהתאם לשיטה שהוחלה על ה-TaskCompletionSource. אם זה עדיין לא ברור, בואו נסתכל על דוגמה זו של קוד, שבה איזשהו ממשק API ישן של EAP עטוף במשימה באמצעות TaskCompletionSource: כאשר האירוע יופעל, המשימה תמוקם במצב Completed, והשיטה שהחילה את האופרטור await למשימה זו תחדש את ביצועה לאחר קבלת האובייקט תוצאה.

public static Task<Result> DoAsync(this SomeApiInstance someApiObj) {

    var completionSource = new TaskCompletionSource<Result>();
    someApiObj.Done += 
        result => completionSource.SetResult(result);
    someApiObj.Do();

    result completionSource.Task;
}

טיפים וטריקים של TaskCompletionSource

גלישת ממשקי API ישנים אינה כל מה שניתן לעשות באמצעות TaskCompletionSource. שימוש במחלקה זו פותחת אפשרות מעניינת לעצב ממשקי API שונים על משימות שאינן תופסות שרשורים. והזרם, כזכור, הוא משאב יקר ומספרם מוגבל (בעיקר בכמות ה-RAM). מגבלה זו יכולה להיות מושגת בקלות על ידי פיתוח, למשל, יישום אינטרנט טעון עם היגיון עסקי מורכב. בואו נשקול את האפשרויות שאני מדבר עליהן בעת ​​יישום טריק כזה כמו Long-Polling.

בקיצור, מהות הטריק היא כזו: אתה צריך לקבל מידע מה-API על כמה אירועים שמתרחשים בצד שלו, בעוד ה-API, משום מה, לא יכול לדווח על האירוע, אלא רק להחזיר את המצב. דוגמה לכך היא כל ממשקי ה-API שנבנו על גבי HTTP לפני זמני WebSocket או כאשר אי אפשר מסיבה כלשהי להשתמש בטכנולוגיה זו. הלקוח יכול לשאול את שרת ה-HTTP. שרת ה-HTTP אינו יכול בעצמו ליזום תקשורת עם הלקוח. פתרון פשוט הוא סקר לשרת באמצעות טיימר, אבל זה יוצר עומס נוסף על השרת ועיכוב נוסף בממוצע TimerInterval / 2. כדי לעקוף את זה, הומצא טריק בשם Long Polling, הכולל עיכוב התגובה מה- שרת עד שפג תוקף הזמן הקצוב או שיתרחש אירוע. אם האירוע התרחש, הוא מעובד, אם לא, הבקשה נשלחת שוב.

while(!eventOccures && !timeoutExceeded)  {

  CheckTimout();
  CheckEvent();
  Thread.Sleep(1);
}

אבל פתרון כזה יתגלה כאיום ברגע שמספר הלקוחות הממתינים לאירוע יגדל, כי... כל לקוח כזה תופס חוט שלם שמחכה לאירוע. כן, ואנו מקבלים עיכוב נוסף של 1ms כאשר האירוע מופעל, לרוב זה לא משמעותי, אבל למה להחמיר את התוכנה ממה שהיא יכולה להיות? אם נסיר את Thread.Sleep(1), אז לשווא נעמיס ליבת מעבד אחת ב-100% סרק, מסתובב במחזור חסר תועלת. באמצעות TaskCompletionSource אתה יכול בקלות ליצור מחדש את הקוד הזה ולפתור את כל הבעיות שזוהו לעיל:

class LongPollingApi {

    private Dictionary<int, TaskCompletionSource<Msg>> tasks;

    public async Task<Msg> AcceptMessageAsync(int userId, int duration) {

        var cs = new TaskCompletionSource<Msg>();
        tasks[userId] = cs;
        await Task.WhenAny(Task.Delay(duration), cs.Task);
        return cs.Task.IsCompleted ? cs.Task.Result : null;
    }

    public void SendMessage(int userId, Msg m) {

        if (tasks.TryGetValue(userId, out var completionSource))
            completionSource.SetResult(m);
    }
}

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

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

ValueTask: למה ואיך

האופרטורים ה-async/await, כמו אופרטור החזרת תשואה, מייצרים מהשיטה מכונת מצב, וזוהי יצירת אובייקט חדש, שכמעט תמיד אינו חשוב, אך במקרים נדירים היא עלולה ליצור בעיה. המקרה הזה עשוי להיות שיטה שנקראת לעתים קרובות מאוד, אנחנו מדברים על עשרות ומאות אלפי שיחות בשנייה. אם שיטה כזו כתובה בצורה כזו שברוב המקרים היא מחזירה תוצאה עוקפת את כל שיטות ה-await, אז .NET מספק כלי לייעל זאת - מבנה ValueTask. כדי להבהיר את זה, בואו נסתכל על דוגמה לשימוש בו: יש מטמון שאנחנו הולכים אליו לעתים קרובות מאוד. יש בו כמה ערכים ואז אנחנו פשוט מחזירים אותם; אם לא, אז אנחנו הולכים לאיזה IO איטי כדי לקבל אותם. אני רוצה לעשות את האחרון בצורה אסינכרונית, מה שאומר שכל השיטה מתבררת כא-סינכרונית. לפיכך, הדרך הברורה לכתיבת השיטה היא כדלקמן:

public async Task<string> GetById(int id) {

    if (cache.TryGetValue(id, out string val))
        return val;
    return await RequestById(id);
}

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

public Task<string> GetById(int id) {

    if (cache.TryGetValue(id, out string val))
        return Task.FromResult(val);
    return RequestById(id);
}

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

public ValueTask<string> GetById(int id) {

    if (cache.TryGetValue(id, out string val))
        return new ValueTask<string>(val);
    return new ValueTask<string>(RequestById(id));
}

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

TaskSchedulers: ניהול אסטרטגיות השקת משימות

ה-API הבא שהייתי רוצה לשקול הוא המחלקה מתזמן משימות ונגזרותיו. כבר הזכרתי למעלה של-TPL יש את היכולת לנהל אסטרטגיות להפצת משימות על פני אשכולות. אסטרטגיות כאלה מוגדרות בצאצאי המחלקה TaskScheduler. כמעט כל אסטרטגיה שאולי תצטרך תמצא בספרייה. תוספות מקבילות תוספות, פותח על ידי מיקרוסופט, אך אינו חלק מ-.NET, אלא מסופק כחבילת Nuget. בואו נסתכל בקצרה על כמה מהם:

• CurrentThreadTaskScheduler - מבצע משימות בשרשור הנוכחי
• LimitedConcurrencyLevel Task Scheduler - מגביל את מספר המשימות המבוצעות בו זמנית על ידי פרמטר N, המקובל בבנאי
• OrderedTaskScheduler - מוגדר כ- LimitedConcurrencyLevelTaskScheduler(1), כך שהמשימות יבוצעו ברצף.
• WorkStealingTaskScheduler - מיישם גניבת עבודה גישה לחלוקת משימות. בעיקרו של דבר זהו ThreadPool נפרד. פותר את הבעיה שב-.NET ThreadPool היא מחלקה סטטית, אחת לכל היישומים, מה שאומר שעומס יתר שלה או שימוש לא נכון בחלק אחד של התוכנית עלול להוביל לתופעות לוואי בחלק אחר. יתרה מכך, קשה מאוד להבין את הסיבה לליקויים כאלה. זֶה. ייתכן שיהיה צורך להשתמש ב-WorkStealingTaskSchedulers נפרדים בחלקים מהתוכנית שבהם השימוש ב-ThreadPool עשוי להיות אגרסיבי ובלתי צפוי.
• QueuedTaskScheduler — מאפשר לך לבצע משימות לפי כללי תור עדיפות
• ThreadPerTaskScheduler - יוצר שרשור נפרד עבור כל משימה שמתבצעת בו. יכול להיות שימושי עבור משימות שלוקח זמן רב באופן בלתי צפוי לביצוע.

יש מפורט טוב מאמר על TaskSchedulers בבלוג של מיקרוסופט.

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

PLinq והמחלקה המקבילה

בנוסף ל-Tasks ולכל מה שנאמר עליהם, יש עוד שני כלים מעניינים ב-.NET: PLinq (Linq2Parallel) והמחלקה Parallel. הראשון מבטיח ביצוע מקביל של כל פעולות Linq במספר שרשורים. ניתן להגדיר את מספר השרשורים באמצעות שיטת ההרחבה WithDegreeOfParallelism. למרבה הצער, לרוב ל-PLinq במצב ברירת המחדל אין מספיק מידע על הפנימיות של מקור הנתונים שלך כדי לספק שיפור מהירות משמעותי, מצד שני, עלות הניסיון נמוכה מאוד: אתה רק צריך להתקשר לשיטת AsParallel לפני שרשרת שיטות Linq והפעלת מבחני ביצועים. יתרה מכך, ניתן להעביר מידע נוסף ל-PLinq על אופי מקור הנתונים שלך באמצעות מנגנון המחיצות. אתה יכול לקרוא עוד כאן и כאן.

המחלקה Parallel static מספקת שיטות לאיטרציה דרך אוסף Foreach במקביל, ביצוע לולאת For וביצוע מספר נציגים ב-Invoke מקביל. ביצוע השרשור הנוכחי יופסק עד להשלמת החישובים. ניתן להגדיר את מספר השרשורים על ידי העברת ParallelOptions כארגומנט האחרון. אתה יכול גם לציין TaskScheduler ו-CancelationToken באמצעות אפשרויות.

ממצאים

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

מסקנות:

• אתה צריך להכיר את הכלים לעבודה עם שרשורים, אסינכרון ומקביליות כדי להשתמש במשאבים של מחשבים אישיים מודרניים.
• ל-.NET יש כלים רבים ושונים למטרות אלו
• לא כולם הופיעו בבת אחת, כך שלעתים קרובות אתה יכול למצוא מדור קודם, עם זאת, יש דרכים להמיר ממשקי API ישנים ללא מאמץ רב.
• עבודה עם שרשורים ב-.NET מיוצגת על ידי המחלקות Thread ו-ThreadPool
• השיטות Thread.Abort, Thread.Interrupt ו-Win32 API TerminateThread מסוכנות ואינן מומלצות לשימוש. במקום זאת, עדיף להשתמש במנגנון CancellationToken
• זרימה היא משאב רב ערך וההיצע שלו מוגבל. יש להימנע ממצבים שבהם שרשורים עסוקים בהמתנה לאירועים. בשביל זה נוח להשתמש במחלקה TaskCompletionSource
• כלי ה-.NET החזקים והמתקדמים ביותר לעבודה עם מקביליות וא-סינכרון הם Tasks.
• האופרטורים c# async/await מיישמים את הרעיון של המתנה לא חוסמת
• אתה יכול לשלוט בהפצה של משימות על פני אשכולות באמצעות מחלקות הנגזרות מ-TaskScheduler
• מבנה ValueTask יכול להיות שימושי באופטימיזציה של נתיבים חמים ותנועת זיכרון
• חלונות המשימות והשרשורים של Visual Studio מספקים מידע שימושי רב לאיתור באגים בקוד מרובה-שרשורים או אסינכרוני
• PLinq הוא כלי מגניב, אבל אולי אין לו מספיק מידע על מקור הנתונים שלך, אבל ניתן לתקן זאת באמצעות מנגנון החלוקה
• להמשך ...

מקור: www.habr.com