لماذا الحظر: الأسباب وراء الحظر المدمر للعقود الآجلة التي تم إرجاعها بواسطة std::async

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

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

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

تعمل أداة تدمير الحظر بمثابة ضمانة ضد هذه المخاطر المحتملة تمنع الخيط المرتبط من مواصلة التنفيذ بعد تدمير المستقبل. ومع ذلك، من المهم ملاحظة أن هذا السلوك خاص بالعقود الآجلة التي يتم إرجاعها بواسطة std::async مع سياسة الإطلاق غير المتزامنة. العقود الآجلة الأخرى، مثل تلك التي يتم إرجاعها بواسطة std::promise أو العقود الآجلة من الخوارزميات المتوازية، لا تظهر نفس سلوك الحظر في أدوات تدميرها.

على الرغم من المخاوف المتعلقة بالسلامة التي أثيرت، فإن أداة تدمير العقود الآجلة std::async لقد كان موضوعًا للنقاش المستمر داخل لجنة التقييس C. لم يتم تبني التغييرات المقترحة لإهمال سلوك الحظر أو جعله غير قياسي للعقود الآجلة غير المتزامنة.

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