التفكير في std::lock_guard vs.std::scoped_lock

يمثل C 17 مقدمة لفئة قفل جديدة، std::scoped_lock ، والتي تتشابه مع std::lock_guard الموقر. تتعمق هذه المقالة في الفروق بين آليتي القفل هاتين، وترشدك في اختيار الأداة المثالية لاحتياجاتك المحددة.

متى تستخدم std::lock_guard

] في السيناريوهات التي تتطلب فيها قفل كائن مزامنة واحد لكامل النطاق، يقدم std::lock_guard واجهة برمجة تطبيقات أكثر أمانًا من std::scoped_lock. خذ بعين الاعتبار المثال التالي:

{ std::scoped_lock قفل؛ // حماية هذه الكتلة ...

{
    std::scoped_lock lock;  // protect this block
    ...
}

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

{ std::scoped_lock lock{mut}; // حماية هذه الكتلة ...

{
    std::scoped_lock lock;  // protect this block
    ...
}

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

{ std::scoped_lock(lock1, lock2); // حماية هذه الكتلة ...

يقوم هذا المقتطف بإيجاز بتأمين كائنين من كائنات المزامنة طوال مدة الكتلة.

الاستنتاج

{
    std::scoped_lock(lock1, lock2);  // protect this block
    ...
}

std::lock_guard لقفل كائن مزامنة واحد عبر النطاق.

std::scoped_lock لقفل كائنات المزامنة المتعددة أو لإلغاء القفل داخل النطاق المغلق.

بينما يوفر std::scoped_lock وظائف أكثر شمولاً، يوفر std::lock_guard أمانًا محسنًا لواجهة برمجة التطبيقات (API) في حالات محددة. خذ بعين الاعتبار متطلبات التعليمات البرمجية الخاصة بك بعناية عند اختيار النهج الأنسب.