Win32 Thread Pool API — מקביליות בלי ליצור תהליכונים, דרך CreateThreadpoolWork

“‏CreateThread אחד לכל לקוח.” “אחד לטיימר.” “אחד להמתנה לאירוע.” — בקוד נייטיב של Windows, תהליכונים נוטים להתרבות כך. כל תהליכון צורך מחסנית ואובייקט ליבה, וגם ליצירה ולהשמדה יש עלות. העבודה עדינה, והתהליכון כבד — מאגר התהליכונים הוא מה שמערכת ההפעלה מספקת כדי לספוג את אי-ההתאמה הזו.

הנוחות של ThreadPool ו-Task.Run ב-.NET ידועה היטב, אבל למעשה גם לנייטיב של Win32 יש API מעוצב היטב, סטנדרטי של מערכת ההפעלה, למאגר תהליכונים. ה-API הזה, שעוצב מחדש באופן מקיף ב-Windows Vista, הוא היסוד של מקביליות נייטיב: הוא יכול לטפל בעבודה, בטיימרים, בהמתנות וב-I/O אסינכרוני דרך מנגנון קריאה חוזרת מאוחד. מיועד למפתחות ולמפתחים שכותבים יישומי Windows, שירותים ו-DLL ב-C/C++, המאמר מסביר את המבנה והשימוש ב-API הזה, ואת המלכודות שקל ליפול אליהן, על בסיס מקורות ראשוניים.

1. השורה התחתונה קודם

• להנפקת מספר גדול של עבודות קצרות-חיים, ולהחלפת תהליכונים שרק ממתינים, מאגר תהליכונים עדיף על CreateThread עצמאי. משאירים את ניהול התהליכונים למערכת ההפעלה ואפשר להקטין את מספר התהליכונים ואת החלפות ההקשר.¹
• מה שצריך להשתמש בו הוא ה-API החדש (משפחת CreateThreadpoolWork). עיצוב מחדש ב-Vista הפך אותו לפשוט יותר, אמין יותר ובעל ביצועים גבוהים יותר מה-API הישן (משפחת QueueUserWorkItem), ואפשר גם ליצור כמה מאגרים עצמאיים בתהליך אחד.¹²
• יש ארבעה סוגי אובייקט. work, שאליו מגישים עבודות; timer, שנורה בזמן או במחזור; wait, שנורה כשאובייקט ליבה מסומן; ו-io, שנורה כש-I/O אסינכרוני מסתיים. כולם רוכבים על אותו מנגנון קריאה חוזרת.³
• כיבוי הוא “המתן, ואז סגור”. משמעת של לא להשאיר קריאה חוזרת רצה מאחור — המתנה להשלמה עם משפחת WaitForThreadpoolWorkCallbacks, או טיפול מרוכז דרך קבוצת ניקוי — נדרשת.⁴
• בתוך קריאה חוזרת: אל תחסמו זמן ארוך (אם כן, CallbackMayRunLong); אל תמתינו סינכרונית להשלמה באותו מאגר; אל תלכלכו את מצב התהליכון. אלה שלושה כללי ברזל.⁵⁶
• שימוש מתוך DLL: שימו לב למירוץ פריקה. המתינו להשלמה בפונקציית כיבוי מפורשת, והכירו את ה-API הייעודיים כמו FreeLibraryWhenCallbackReturns.³

2. למה מאגר, ומתי מאגר

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

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

• יישומים שמנפיקים מספר גדול של פריטי עבודה קטנים במקביל (חיפוש, I/O רשת וכדומה)
• יישומים שיוצרים ומפרקים לעיתים קרובות תהליכונים קצרי-חיים
• יישומים שמעבדים עבודה עצמאית במקביל ברקע
• יישומים שמחזיקים תהליכונים המוקדשים להמתנה לאובייקטי ליבה או לאירועים

הפריט האחרון קל לפספס. אם יש לכם חמישה תהליכונים שקיימים רק כדי לישון כדי שיוכלו “לרוץ כשהאירוע מסומן”, אפשר להחליף אותם בחמישה אובייקטי wait על המאגר, וההמתנה מתרכזת על תהליכוני ההמתנה של המאגר.

ולהפך, יש גם עבודה שלא מתאימה למאגר. עבודה שצריכה שינוי עדיפות תהליכון, שדורשת COM STA, שממשיכה לרוץ לכל חיי התהליך — עבודה שצריכה “אישיות” על התהליכון מוחזקת על תהליכון ייעודי. תהליכון עבודה הוא משאב משותף; שואלים אותו.

flowchart TB
    accTitle: בחירה בין תהליכון ייעודי למאגר
    accDescr: קודם בודקים אם נדרשת אישיות תהליכון כמו עדיפות או STA, ואם זה רץ זמן ארוך; רק עבודה קצרת-חיים, בנפח גבוה או בסגנון המתנה שלא מתאימה לאף אחד מאלה הולכת למאגר התהליכונים
    q1{"צריך אישיות כמו עדיפות או STA?"} -->|"כן"| ded["להשאיר על תהליכון ייעודי"]
    q1 -->|"לא"| q2{"האם זה רץ זמן ארוך?"}
    q2 -->|"כן"| ded
    q2 -->|"לא"| pool["לשים על מאגר התהליכונים"]
    pool -.-> ex["עבודה קצרה, המתנות, טיימרים, השלמות I/O"]

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

יש גם פיסת היסטוריה אחת לקבע. ל-API של מאגר התהליכונים יש שני דורות. ה-API הישן שנמשך מאז Windows 2000 ‏(QueueUserWorkItem, RegisterWaitForSingleObject וכדומה), וה-API החדש שעוצב מחדש באופן מקיף ב-Vista (משפחת CreateThreadpoolWork). ה-API החדש מאחד את סוגי תהליכון העבודה, מספק תהליכונים מתמידים ייעודיים, כמה מאגרים בתהליך אחד, קבוצות ניקוי ועוד, והתיעוד הרשמי קובע במפורש שהוא “פשוט יותר, אמין יותר, בעל ביצועים טובים יותר וגמיש יותר”.¹ ל-API הישן יש גם אילוצים מבניים כמו “אי אפשר לבטל עבודה ברגע שהיא בתור”.² מכאן ואילך המאמר מטפל רק ב-API החדש.

flowchart TB
    accTitle: ההתאמה בין ה-API הישן של מאגר התהליכונים ל-API החדש
    accDescr: QueueUserWorkItem של ה-API הישן ממופה לאובייקט work של ה-API החדש, תורי טיימר ל-timer, המתנות רשומות ל-wait, ו-BindIoCompletionCallback ל-io
    o1["QueueUserWorkItem"] --> n1["work"]
    o2["תורי טיימר"] --> n2["timer"]
    o5["המתנות רשומות"] --> n3["wait"]
    o4["BindIoCompletionCallback"] --> n4["io"]

איור 2: יעד ההעברה מה-API הישן הוא אחד-לאחד. מלאי של קוד קיים יכול להתחיל מההתאמה הזו.

3. ארבעת האובייקטים — work, timer, wait ו-io

במרכז ה-API החדש עומדים ארבעה סוגי אובייקט שתנאי הירי של הקריאה החוזרת שלהם שונים.³

flowchart TB
    accTitle: ארבעת האובייקטים של מאגר התהליכונים ומנגנון הקריאה החוזרת
    accDescr: work נורה בהגשה מפורשת, timer בזמן, wait בסימון אובייקט ליבה, ו-io בהשלמת I/O אסינכרוני; כולם רצים כקריאות חוזרות על אותה קבוצת תהליכוני עבודה
    kind{"איזה אובייקט?"}
    kind --> w["work（בהגשה）"]
    kind --> more{"טיימר, המתנה או io?"}
    more --> t["timer（זמן / מחזור）"]
    more --> rest{"המתנה או io?"}
    rest --> wt["wait（בסימון）"]
    rest --> io["io（השלמת I/O）"]
    w --> pool["העובדים מריצים קריאה חוזרת"]
    t --> pool
    wt --> pool
    io --> pool

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

האיחוד הזה הוא חוזק מעשי. במקום לכתוב עיבוד מחזורי, תגובה לאירוע ועיבוד השלמת I/O כל אחד על תהליכון ייעודי, אפשר ליישר אותם לסגנון קריאה חוזרת אחד. טיימרים מרוכזים לתור טיימר יחיד לכל המאגר, והמתנות מרוכזות על מספר קטן של תהליכוני המתנה — תהליכונים ש”רק ישנים” נעלמים מהתהליך.¹

flowchart TB
    accTitle: החלפת תהליכונים שרק ממתינים באובייקטי wait
    accDescr: תהליכונים שרק ממתינים ושנהגו לישון אחד לכל אירוע הופכים לאובייקטי wait ומרוכזים על תהליכוני ההמתנה של המאגר, כך שהקריאה החוזרת רצה רק כשיש סימון
    old2["5 תהליכוני המתנה ייעודיים ישנים בנפרד"] -.-> waste["צורך 5 מחסניות ו-5 תהליכונים"]
    new2["5 אובייקטי wait"] --> agg["ריכוז על תהליכוני ההמתנה של המאגר"]
    agg --> cb2["הקריאה החוזרת רצה רק בסימון"]

איור 4: תהליכונים ש”רק ישנים וממתינים” אפשר להסיר בהפיכתם לאובייקטי wait. זה מהלך ראשון ברור להעברה למאגר.

4. התבנית הבסיסית — הלוך ושוב אחד עם אובייקט work

עוברים פעם אחת על הנימוסים עם אובייקט work, שהוא הנפוץ ביותר.⁴

VOID CALLBACK WorkCallback(PTP_CALLBACK_INSTANCE instance,
                           PVOID context, PTP_WORK work)
{
    // ההקשר קבוע בזמן היצירה. נתונים לכל פריט עוברים דרך תור מסונכרן
    WORK_QUEUE* queue = (WORK_QUEUE*)context;
    ITEM* item = Dequeue(queue);        // לקיחת פריט אחד תחת שליטה בלעדית
    ProcessItem(item);
}

// 1) יצירה (קישור הקריאה החוזרת להקשר המשותף = התור)
PTP_WORK work = CreateThreadpoolWork(WorkCallback, &queue, NULL);
if (!work) { /* טיפול בכישלון עם GetLastError */ }

// 2) הגשה אחת לכל פריט שמוכנס לתור (לשמור על מספר הפריטים ומספר ההגשות צמודים)
Enqueue(&queue, item);
SubmitThreadpoolWork(work);

// 3) עצירת המגיש, ואז המתנה להשלמה (TRUE מנסה גם לבטל עבודה שעדיין לא התחילה)
WaitForThreadpoolWorkCallbacks(work, FALSE);

// 4) סגירה
CloseThreadpoolWork(work);

יש שתי נקודות להחזיק. ראשית, מותר לעשות SubmitThreadpoolWork לאותו אובייקט work יותר מפעם אחת. כל הגשה מריצה את הקריאה החוזרת (במקביל).⁷ עם זאת, ההקשר שמועבר לקריאה החוזרת קבוע בזמן היצירה, כך שכשכותבים “N פריטים מאותו סוג עבודה” עם אובייקט work אחד, שמים תור מסונכרן בהקשר כמו בקוד למעלה ולוקחים פריט אחד לכל הגשה (גם תכנון שיוצר אובייקט work לכל פריט תקין). שנית, תמיד ממתינים להשלמה לפני שסוגרים. סגירת האובייקט בזמן שנשארת קריאה חוזרת רצה או בתור, או שחרור זיכרון שהקריאה החוזרת מתייחסת אליו, הוא use-after-free כמות שהוא. כדי שההמתנה הזו תהיה סגירה בטוחה, עצירת המגיש קודם היא תנאי מוקדם — במבנה שבו תהליכון אחר עדיין יכול לעשות Submit במקביל להמתנה, הגשה אחרי ההמתנה מתחרה עם Close. העברת TRUE כארגומנט השני של WaitForThreadpoolWorkCallbacks מנסה גם לבטל הגשות שעדיין לא התחילו.

flowchart TB
    accTitle: מחזור החיים של אובייקט work
    accDescr: יצירה עם CreateThreadpoolWork; הגשה עם SubmitThreadpoolWork והקריאות החוזרות רצות במקביל. בכיבוי, קודם עוצרים הגשות חדשות, ממתינים להשלמת כל הקריאות החוזרות עם WaitForThreadpoolWorkCallbacks, ואז סוגרים עם CloseThreadpoolWork
    c["יצירה עם CreateThreadpoolWork"] --> s["הגשה עם SubmitThreadpoolWork （אפשר לחזור）"]
    s --> run["קריאות חוזרות רצות במקביל"]
    run --> stop3["עצירת הגשות חדשות"]
    stop3 --> w["המתנה להשלמה עם WaitForThreadpoolWorkCallbacks"]
    w --> cl["סגירה עם CloseThreadpoolWork"]

איור 5: סדר הכיבוי הוא “עצירת הגשות → המתנה להשלמה → סגירה”. מדלגים על אחד מהם ומקבלים use-after-free או מירוץ.

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

5. מאגרים מותאמים וקבוצות ניקוי

פצלו את המאגר. אפשר ליצור מאגר עצמאי עם CreateThreadpool ולהגדיר את התקרה והרצפה של מספר התהליכונים עם SetThreadpoolThreadMaximum / SetThreadpoolThreadMinimum.⁸ השימוש הטיפוסי הוא בידוד. כדי ש”עבודה דמוית-אצווה שעלולה להיות איטית” לא תאכל את העובדים של “עבודה שצריכה להגיב מיד”, מפצלים את המאגרים ונותנים לכל אחד תקציב תהליכונים משלו.

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

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

flowchart TB
    accTitle: קישור התצורה דרך סביבת קריאה חוזרת
    accDescr: סביבת הקריאה החוזרת מצביעה על מאגר מותאם ועל קבוצת ניקוי; work ו-timer שנוצרו עם הסביבה הזו רצים על המאגר הזה, ופעולה מרוכזת על קבוצת הניקוי אוספת המתנה להשלמה ושחרור
    env["סביבת קריאה חוזרת （TP_CALLBACK_ENVIRON）"] --> cp["מאגר מותאם （שליטה במספר התהליכונים）"]
    env --> cg["קבוצת ניקוי"]
    env --> obj["מועבר ביצירת work / timer / wait / io"]
    cg -.-> close["המתנה להשלמה ושחרור במכה אחת"]

איור 6: סביבת קריאה חוזרת היא המנגנון שמזריק “על איזה מאגר זה רץ, ומי מנקה” בזמן יצירת האובייקט.

6. מלכודות — משמעת בתוך קריאה חוזרת

כמעט כל באג במאגר תהליכונים מגיע מ”לעשות כרצונכם על תהליכון שאול”.

חסימה ממושכת. המאגר מתאים את מספר התהליכונים מתוך הנחה שהקריאות החוזרות חוזרות במהירות. עבודה ארוכה או המתנה ארוכה בברירות המחדל מעכבת את ביצוע הקריאות החוזרות האחרות. קריאה חוזרת שעלולה לרוץ זמן ארוך צריכה להכריז “זו תרוץ זמן ארוך” עם CallbackMayRunLong (המאגר לוקח זאת כרמז להוסיף תהליכון), או להישלח מלכתחילה לתהליכון ייעודי. שימו לב ש-CallbackMayRunLong מחזיר FALSE כשאינו יכול להכין עובד לקריאות חוזרות אחרות. אם ממשיכים לחסום בלי לבדוק את ערך ההחזרה עדיין סותמים את המאגר, ולכן כשזה FALSE, נופלים לצד שלא חוסם — פיצול העבודה, שליחה לתהליכון ייעודי וכדומה.⁵

המתנה סינכרונית להשלמה באותו מאגר. צורה שבה, בתוך קריאה חוזרת A, ממתינים עם WaitForThreadpoolWorkCallbacks או דומה להשלמת עבודה B שהוגשה לאותו מאגר הופכת לקיפאון מרעב-מאגר ברגע שכל עובד “ממתין לעובד אחר”. כתבו מחדש תלות בין עבודות לא כהמתנה אלא כהמשך ש”מגיש את הבא מקריאת ההשלמה של B”.

flowchart TB
    accTitle: המבנה של קיפאון מרעב-מאגר
    accDescr: אם כל תהליכון עבודה ממתין סינכרונית להשלמת עבודה אחרת שהוגשה לאותו מאגר, לא נשאר עובד פנוי להריץ את העבודה הזו, והכול ממתין לנצח
    w1["עובד 1: ממתין להשלמת עבודה X"] --> q["עבודות X ו-Y ממתינות לריצה"]
    w2["עובד 2: ממתין להשלמת עבודה Y"] --> q
    q -.-> none["אין עובד פנוי להריץ אותן"]
    none -.-> dead["הכול ממתין לנצח （קיפאון רעב）"]

איור 7: אם ממתינים סינכרונית לעובד מתוך עובד, לא נשאר מי שיריץ את העבודה שממתינים לה.

לכלוך מצב התהליכון. תהליכון עבודה ממוחזר לקריאה החוזרת הבאה. שינוי עדיפות תהליכון, מצב אתחול COM, ערך שנשאר ב-TLS, נעילה ששכחתם לעזוב — כל אחד מאלה הופך לזיהום של הקריאה החוזרת הבאה (שאינה קשורה). “פונקציה שזורקים למאגר אסור שתהיה תלויה באישיות התהליכון” היא אזהרה רשמית עוד מימי ה-API הישן.⁶ יש מנגנונים ייעודיים לניקוי; למשל, LeaveCriticalSectionWhenCallbackReturns יכול לבקש מהמאגר “שחרר את הנעילה הזו כשהקריאה החוזרת הזו חוזרת”.³

מירוץ עם פריקת DLL. אם ה-DLL שמכיל את הקוד נפרק בזמן שקריאה חוזרת רצה, מתקבלת הפרת גישה. הצורה הבסיסית היא להמתין ביסודיות להשלמה בפונקציית הכיבוי של ה-DLL; FreeLibraryWhenCallbackReturns מסופק למצב “הקריאה החוזרת הזו היא העבודה האחרונה, וכשהיא מסתיימת אני רוצה שה-DLL ישוחרר כולל אני עצמי”. ה-API הזה, עם זאת, רק “מרפה מאזכור אחד כשהקריאה החוזרת הרצה חוזרת”; הוא לא מונע פריקה לפני שהקריאה החוזרת התחילה. משתמשים בו כזוג: לוקחים אזכור מודול משלכם עם GetModuleHandleEx לפני ההגשה, ונותנים לקריאה החוזרת להרפות מהאזכור הזה עם ה-API הזה.³ ואל תעשו את ההמתנה להשלמה הזו בתוך DllMain — כפי שנאמר ב”DllMain ונעילת הטוען”, המתנה לתהליכון אחר בתוך DllMain היא תבנית קיפאון.

flowchart TB
    accTitle: הכנה למירוץ בין פריקת DLL לקריאה חוזרת
    accDescr: פריקת ה-DLL בזמן שקריאה חוזרת רצה הופכת להפרת גישה, ולכן הצורה הבסיסית היא להמתין להשלמה בפונקציית כיבוי מפורשת ואז לסגור; כשהקריאה החוזרת האחרונה עצמה משחררת את ה-DLL, משתמשים ב-FreeLibraryWhenCallbackReturns
    risk["פריקה במהלך קריאה חוזרת"] -.-> av["הפרת גישה"]
    g1["המתנה, ואז סגירה"] --> safe["פריקה בטוחה"]
    g1 -.-> g1N["בפונקציית כיבוי"]
    g2["FreeLibraryWhenCallbackReturns"] --> safe
    g2 -.-> g2n["הקריאה האחרונה משחררת DLL"]
    g1 -.-> ng["לא בתוך DllMain"]
    av ~~~ g1

איור 8: הצורה הבסיסית היא לעשות “המתן, ואז סגור” בפונקציית כיבוי מפורשת. המתנה בתוך DllMain מזמינה קיפאון אחר.

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

7. איך זה קשור לספריית התקן ול-.NET — באיזו שכבה כותבים

לבסוף, מסדרים איך זה יושב מול הכלים האחרים.

• אם std::async / std::thread של C++ מספיקים, הם המועמד הראשון. הם ניידים, הקוד קצר, ואפילו הסמנטיקה של future מיושבת בתקן.¹⁰
• סיבות להשתמש במאגר התהליכונים של Win32 ישירות הן כש(1) רוצים מנגנון קריאה חוזרת מאוחד שכולל timer, wait ו-io, (2) רוצים פיצול מאגרים או שליטה במספר תהליכונים, או (3) לא רוצים להחזיק תהליכונים עצמאיים בתוך DLL או רכיב COM.
• בצד .NET, ThreadPool ו-Task ממלאים אותו תפקיד, והשלמת I/O קשורה ל-IOCP. מבנה המרתף הזה מוסבר ב”IOCP ומאגר התהליכונים של .NET”.

flowchart TB
    accTitle: החלטה באילו כלי שכבה לכתוב
    accDescr: אם async או thread של C++ התקני מספיקים, משתמשים בהם; משתמשים במאגר התהליכונים של Win32 ישירות כשצריך שילוב של טיימרים, המתנות והשלמות I/O, פיצול מאגרים או שליטה במספר תהליכונים, או כשלא רוצים תהליכונים עצמאיים בתוך DLL או רכיב COM
    q1{"האם כלי C++ התקניים מספיקים?"} -->|"כן"| std["std::async / std::thread"]
    q1 -->|"לא"| q2{"מה צריך?"}
    q2 -->|"שילוב של timer, wait ו-io"| tp["מאגר תהליכונים של Win32"]
    q2 -->|"פיצול מאגר / שליטה במספר"| tp
    q2 -->|"הימנעות מתהליכונים עצמאיים ב-DLL"| tp

איור 9: בספק, מתחילים בספריית התקן; תורו של ה-API הזה מגיע כשמופיעה דרישה שהוא לא יכול לבטא.

במילים אחרות, ה-API הזה הוא יסוד המקביליות בנקודה שבה החלטתם “לכתוב נייטיב”. ניקוי ריאליסטי הוא מדורג: כיעד העברה מהתרבות CreateThread עצמאי, מתחילים בהכנסת אובייקט work, ואז מחליפים תהליכונים שרק ממתינים ב-wait ותהליכוני טיימר ב-timer.

8. סיכום

• להנפקת מספר גדול של עבודות קצרות-חיים, ולניקוי תהליכונים שרק ממתינים ורק מטיימרים, מאגר התהליכונים הסטנדרטי של מערכת ההפעלה ולא תהליכונים עצמאיים. מה שמשתמשים בו הוא ה-API החדש מ-Vista ואילך.
• במרכז עומדים ארבעת האובייקטים work, timer, wait ו-io. תנאי הירי שונים; הם מאוחדים על אותה קבוצת עובדים ואותו סגנון קריאה חוזרת.
• הנימוסים הם “צור → הגש → המתן להשלמה → סגור”. כמה הגשות רצות במקביל. קבוצת ניקוי יכולה לרכז את עיבוד הכיבוי.
• שלושת כללי הברזל של קריאה חוזרת: אל תחסמו זמן ארוך (אם כן, CallbackMayRunLong); אל תמתינו סינכרונית באותו מאגר; אל תלכלכו את מצב התהליכון.
• שימוש מתוך DLL: שימו לב למירוץ פריקה. המתינו להשלמה בפונקציית כיבוי מפורשת; אל תעשו זאת ב-DllMain.
• היכן ש-C++ תקני או .NET מספיקים, השתמשו בהם. תורו של ה-API הזה הוא כשצריך שילוב של timer/wait/io או שליטה במאגר.

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

מאמרים קשורים

• מעמקי ה-I/O של Windows (חלק 3) — פורטי השלמת I/O ‏(IOCP) ומאגר התהליכונים של .NET: המרתף מתחת ל-async/await
• פרקטיקות מומלצות לריבוי תהליכונים: מהדורת C++ — ביטול תאונות לפי מבנה עם RAII ו-jthread
• פרקטיקות מומלצות לריבוי תהליכונים: מהדורת C — כתיבה בטוחה בדרך של Win32 API
• יקיצות שווא — למה משתני תנאי מתעוררים “בלי לקבל התראה” ואיך להמתין נכון ב-Windows
• DllMain ונעילת הטוען — הסיבה האמיתית שאומרים לכם “אל תעשו כלום באתחול DLL”
• למה עדיף ב-Windows להעדיף המתנות לאירוע על פני Sleep(1)

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בתכנון העברה מקוד נייטיב שתהליכוניו התרבו אל מאגר התהליכונים, בסקירות תכנון של עיבוד מקבילי ביישומי C++ וב-DLL, ובחקירת שורש של תקיעות וקריסות שנגרמו מרעב-מאגר או מקריאות חוזרות. מוזמנים להתייעץ איתנו החל ממלאי של הקוד הקיים.

• פיתוח יישומי Windows
• ייעוץ טכני וסקירת תכנון
• חקירת תקלות ואיתור גורמים
• יצירת קשר

קישורים

מאמרים קשורים

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

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

מה עדיף במאגר תהליכונים לעומת יצירת תהליכונים עצמאיים עם CreateThread?

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

במה זה שונה מפונקציות מאגר התהליכונים הישנות כמו QueueUserWorkItem?

מאגר התהליכונים עוצב מחדש באופן מקיף ב-Windows Vista. ה-API הנוכחי ממשפחת threadpoolapiset (CreateThreadpoolWork וכדומה) הוא ה-API החדש; QueueUserWorkItem, RegisterWaitForSingleObject וכדומה הם ה-API הישן (legacy). ה-API החדש מאחד את סוגי תהליכוני העבודה, מאפשר ליצור כמה מאגרים עצמאיים בתהליך אחד, ומספק מנגנונים כמו שחרור מרוכז דרך קבוצת ניקוי ושחרור נעילה או פריקת DLL הקשורים להשלמת קריאה חוזרת. גם התיעוד הרשמי אומר שה-API החדש פשוט יותר ועדיף באמינות, בביצועים ובגמישות. ל-API הישן יש גם אילוצים מבניים, כמו "אין דרך לבטל עבודה ברגע שהיא בתור", ולכן בקוד חדש משתמשים ב-API החדש.

יש דברים שאסור לעשות בתוך קריאה חוזרת?

יש שלושה גדולים. ראשית, חסימה ממושכת או עבודה ארוכה בברירות המחדל. המאגר מתאים את מספר התהליכונים מתוך הנחה שהקריאות החוזרות מסתיימות במהירות, ולכן לעבודה שתיקח זמן ארוך מכריזים עליה עם CallbackMayRunLong או משתמשים בתהליכון ייעודי. שנית, המתנה סינכרונית להשלמת עבודה אחרת שהגשתם לאותו מאגר. אם כל עובד מגיע למצב "ממתין לעובד אחר", מתקבל קיפאון מרעב-מאגר. שלישית, תלות באישיות התהליכון. תהליכוני עבודה משותפים בין קריאות חוזרות, כך שחזרה עם עדיפות תהליכון או מצב אתחול COM שהשתנו, או השארת מצב ב-TLS, מזהמת את הקריאה החוזרת הבאה. לניקוי בסוף (שחרור נעילה או פריקת DLL) מסופקים מנגנונים ייעודיים כמו LeaveCriticalSectionWhenCallbackReturns ו-FreeLibraryWhenCallbackReturns.

יש נקודות לתשומת לב בשימוש במאגר התהליכונים מתוך DLL?

הסכנה הגדולה ביותר היא "ה-DLL נפרק בזמן שקריאה חוזרת עדיין רצה". אם הקריאה החוזרת רצה אחרי הפריקה, מתקבלת הפרת גישה. צד ה-DLL חייב, בעיבוד הכיבוי שלו, להמתין באופן אמין להשלמת הקריאות החוזרות שהנפיק — עם פונקציית המתנה כמו WaitForThreadpoolWorkCallbacks, או CloseThreadpoolCleanupGroupMembers על קבוצת ניקוי — ורק אז לסגור את האובייקטים. המתנה לזה בתוך DllMain, לעומת זאת, עלולה לקפוא דרך אינטראקציה עם נעילת הטוען, ולכן הכלל הוא לעשות זאת בפונקציית כיבוי מפורשת, לא ב-DllMain. למצב שבו הקריאה החוזרת עצמה רוצה לשחרר את ה-DLL כי "זו העבודה האחרונה", מסופק API ייעודי, FreeLibraryWhenCallbackReturns.

עכשיו שיש C++ std::async ו-ThreadPool של .NET, עדיין יש מקרים להשתמש ב-API הזה ישירות?

יש. הקריטריון הוא "האם הכלי בשכבה הזו מספיק". אם רמת המקביליות שצריך ב-C++ מכוסה ב-std::async או ב-std::thread, ספריית התקן היא המועמד הראשון גם מבחינת ניידות. מצד שני, רצון לאחד טיימרים, המתנות לאובייקטי ליבה והשלמות I/O אסינכרוני במנגנון קריאה חוזרת אחד; רצון לפצל מאגרים ולשלוט במספר תהליכונים לפי סוג עבודה; אי-רצון להחזיק תהליכונים עצמאיים בתוך DLL או רכיב COM — אלה הדרישות שמאגר התהליכונים של Win32 מכסה. הקשר עם ThreadPool ו-IOCP של .NET מכוסה במאמר קשור, וכל עוד כותבים נייטיב, הכרת המנגנון שיושב בשכבה מתחת אינה מבוזבזת.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.