-----------------------------------------------------------------

אז מה קורה בקוד שלנו היום?
בקוד יש פונקציה שמשנה את העובד שנמצא כרגע בסניף שלנו.
הקוד שלנו כמובן thread safe, ולכן אנחנו נועלים איזשהו mutex
בתחילת קוד. אחריו, אנחנו שומרים רפרנס לעובד הקודם(כדי שאם העובד הנוכחי יחליק וישבור את הרגל, נוכל לקרוא לעובד הקודם שיחליף אותו )
- יש להניח שהשורה הזאת בסדר(מי שכותב קוד כמו שכתוב בשורה הזו, מגיע לו כנראה לקבל צו הרחקה מ visual studio, אבל לצורך העניין, לא היה לי כוח לכתוב את זה יותר יפה אז תניחו שזה עובד).

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

יופי טופי, הכל עובד כמו שצריך.....
האמנם?

void MyClass::replaceEmployee() {

    lock(m_mutex);

    *m_lastEmployee = *m_employee; // This line is ok, as the type has overloaded the = operator to copy the entire object

    delete m_employee; // Free the last employee memory

    m_employee = new Employee("Nice Guy");

    unlock(m_mutex); 
}

אבל מקרה שיכול להיות פה
זה שנקבל exception בשלב שבין ה lock ל unlock
יחול תהליך של stack unwinding וכל האובייקטים שלנו יהרוס.
אבל ה mutex שלנו ישאר נעול.
וכך נגיע למצב שבקריאה הבאה לפונקציה שלנו אנחנו נתקע\נכשל (במידה ויש איזה timeout)

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

הפתרון? RAII - Resource Acquisition Is Initialization.
זה design pattern מדהים, שבשיא הכנות - שינה את "חיי התכנות" ברגע שהכרתי אותו
הוא מספק פתרון אלגנטי להמון בעיות בתחום ה- resource management.
הרעיון: ברגע שיוצרים אובייקט כלשהו - אנחנו עושים פעולת "הרכשה" - ובהריסה שלו - נעשה פעולת "שחרור".

איך זה נראה:

class Lock {
public:
 Lock(Mutex& mutex) { lock(mutex); }
 ~Lock()  { unlock(mutex); };
};

בצורה הזו נבטיח שברגע שנצא מה- Scope, בין אם בצורה טובה ובין אם זה קרה בגלל exception,
תמיד, אבל תמיד נשחרר את הmutex שלנו.
ה-DESIGN PATTERN הזה מצויין לעבודה עם כל משאב - קובץ, וכל דבר כזה למעשה, אם ניגשים
אליו ברמת scope ולא בצורה גלובלית.

אבל צריך לשים לב שלא רק ה mutex ישאר נעול - אלא גם שאנחנו הכנסו את המחלקה למצב זומבי מוזר,
כי m_employee מצביע עכשיו למקום לא ברור - אובייקט שכבר נמחק.
מעבר לזה שזו בעית אבטחה רצינית(אם למשתמש יש שליטה על מה שמחקתם, אפשר לנצל את זה לטובת חולשת double free, זה מטורף ומגניב - תקראו על זה),
זה גם יגרום למחלקה שלהם להתנהג בצורה לא צפויה.

לכן - חשוב תמיד להקפיד על עבודה עם excpetion safety בראש.
אגב - פתרון מעולה לבעיה הזו, יהיה להשתמש ב smart pointer. יש מימוש לא רע ב - stl.
אני מציע לכם לנסות לממש כזה smart pointer עם ref count בעצמכם. זה מגניב ולומדים מזה המון.