أنماط التزامن والخطأ المخفية في الكود: Deadlock

بالتأكيد ، سمع الكثيرون ، لكن التقى شخص ما في الممارسة العملية ، مثل كلمات الجمود وظروف السباق. تصنف هذه المفاهيم على أنها أخطاء في استخدام التزامن. إذا طرحت عليك سؤالًا حول الطريق المسدود ، فمن المحتمل جدًا أن تبدأ في رسم صورة جمود كلاسيكية أو تمثيلها في كود زائف دون أي شك. شيء مثل هذا:



نحصل على هذه المعلومات في المعهد ، ويمكن العثور عليها في الكتب والمقالات على الإنترنت. مثل هذا الجمود الذي يستخدم ، على سبيل المثال ، مزيفتان ، بكل مجده ، يمكن العثور عليهما في الكود. لكن في معظم الحالات ، ليس كل شيء بسيطًا للغاية ، ولا يمكن للجميع رؤية نمط الخطأ الكلاسيكي في الكود إذا لم يتم تقديمه في النموذج المعتاد.



ضع في اعتبارك فئة نرغب فيها في أساليب StartUpdate و CheckAndUpdate و Stop ، يتم استخدام C ++ والرمز بسيط قدر الإمكان:

std::recursive_mutex m_mutex; Future m_future; void Stop() { std::unique_lock scoped_lock(m_mutex); m_future.Wait(); // do something } void StartUpdate() { m_future.Wait(); m_future = Future::Schedule(std::bind(&Element::CheckAndUpdate, this), std::chrono::milliseconds(100); } void CheckAndUpdate() { std::unique_lock scoped_lock(m_mutex); //do something } 

ما يجب الانتباه إليه في الكود المقدم:

1. يستخدم mutex العودية. لا يؤدي الالتقاط المتكرر لـ mutex متكرر إلى توقع فقط في حالة حدوث هذه الالتقاط في نفس مؤشر الترابط. في هذه الحالة ، يجب أن يتطابق عدد إعفاءات mutex مع عدد الأسرى. إذا حاولنا التقاط كائن مزامنة متكرر تم التقاطه بالفعل في خيط آخر ، فسيذهب الخيط إلى وضع الاستعداد.
2. تبدأ دالة Future :: Schedule (بالمللي ثانية) في مؤشر ترابط منفصل تم تمرير رد الاتصال إليه

نحلل الآن جميع المعلومات الواردة ونقوم بتكوين صورة:



مع مراعاة الحالتين الموضحتين أعلاه ، ليس من الصعب أن نستنتج أن محاولة التقاط مزامنة متكررة في إحدى الوظائف ستؤدي إلى توقع الإفراج عن المزامنة إذا تم التقاطها بالفعل في وظيفة أخرى ، حيث أن رد الاتصال CheckAndUpdate يتم تنفيذه دائمًا في سلسلة رسائل منفصلة.

للوهلة الأولى ، لا يوجد شيء مشبوه بشأن الجمود. ولكن لكي نكون أكثر قربًا ، كل هذا يعود إلى صورتنا الكلاسيكية. عندما يبدأ تنفيذ الكائن الوظيفي ، نقوم ضمنيًا بالتقاط المورد m_future ، وهو رد الاتصال مباشرة
المرتبطة m_future:



تسلسل الإجراءات التي تؤدي إلى حالة توقف تام كما يلي:

1. من المخطط تشغيل CheckAndUpdate ، لكن رد الاتصال لا يبدأ على الفور ، بعد ميلي ثانية.
2. تسمى طريقة الإيقاف ، ثم تبدأ: نحن نحاول التقاط كائن المزامنة - المورد واحد تم التقاطه ، نبدأ في الانتظار حتى يكتمل m_future - لم يتم استدعاء الكائن بعد ، نحن ننتظر.
3. يبدأ تنفيذ CheckAndUpdate: نحاول القبض على كائن المزامنة - لا يمكننا ذلك ، يتم التقاط المورد بالفعل بواسطة مؤشر ترابط آخر ، نحن في انتظار الإصدار.

هذا كل شيء: ينتظر مؤشر الترابط إجراء المكالمة "إيقاف" لإكمال CheckAndUpdate ، ولا يمكن لمؤشر الترابط الآخر ، بدوره ، أن يستمر في العمل حتى يمسك كائن المزامنة الذي تم التقاطه بالفعل بواسطة الخيط المذكور سابقًا. إنه طريق مسدود كلاسيكي. يتم الانتهاء من نصف العمل - تم اكتشاف سبب المشكلة.


فيما يلي مثال بسيط مع حالة توقف تام غير واضحة تقلل بسهولة إلى نمط هذا الخطأ. وأخيرا ، أود أن أتمنى لك أن تكتب رمز آمن موثوقة وخيط!