לדלג לתוכן

פתרון מסננים וחיי קריאות חוזרות

הפיצול הבא מחליף את stop_and_wait בתוך המחלקה. ההמתנה עדיין דורשת context שמותר לחסום בו ושאינו מחזיק lease פעיל.

void request_stop() {
    std::lock_guard lock(mutex);
    accepting = false;
}
void wait_empty() {
    std::unique_lock lock(mutex);
    empty.wait(lock, [&] { return active == 0; });
}

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

ההוכחה של המונה נשענת על שני דברים: כל enter מוצלח יוצר lease יחיד, וכל lease פעיל מבצע leave אחד. ההעברה בmove מאפסת את הבעלות הישנה ולכן אינה יוצרת שתי יציאות. הפונקציה enter שנדחית אינה מגדילה את המונה.

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

בפריקה סוגרים את מקור העבודה החדשה ומסיימים את העבודה הקיימת לפי סדר התלויות. אם worker ממתין לתשובה מuser mode שכבר נסגר, צריך מסלול כשל שמאפשר לו לצאת. אחרת קיבלנו deadlock בין שני תהליכי shutdown שכל אחד מהם נראה תקין לבדו.

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