استخدام ConfigureAwait(false) مقابل تعيين السياق المتزامن

في عالم تطوير البرمجيات، يشتهر استخدام مكتبات البرمجة الغير متزامنة بضرورة استخدام “ConfigureAwait(false)” في كل استدعاء await لتجنب الاستمرار على سياق التزامن الحالي. هذا المفهوم مهم لأنه يمنع تأثير العمليات الطويلة على تجربة المستخدم أو أداء التطبيق بشكل عام.

ومع ذلك، هناك بديل لتضمين “ConfigureAwait(false)” في جميع أنحاء رمز المكتبة، وهو ببساطة تعيين السياق المتزامن إلى قيمة “null” مرة واحدة فقط، في طريقة السطح العامة العامة، واستعادته قبل العودة إلى المستخدم. بمعنى آخر، يمكن تحقيق الأمر كالتالي:

csharpCopy code
public async Task SomeSurfaceMethod()
{
    var callerSyncCtx = SynchronizationContext.Current;
    SynchronizationContext.SetSynchronizationContext(null);
    try
    {
        // قم بالعمل
    }
    finally
    {
        SynchronizationContext.SetSynchronizationContext(callerSyncCtx);
    }
}

هذا النهج يمكن أيضًا تجميعه في تعليمة “using” لزيادة قراءة الرمز.

فهل هناك عيوب لهذا النهج؟ وهل لا ينتج نفس التأثير؟ الإجابة تكمن في النقاط التالية:

أولاً، الوضوح – إزالة جميع استدعاءات “ConfigureAwait(false)” يزيد من قراءة الرمز. كما أنه قد يقلل من احتمال نسيان “ConfigureAwait(false)” في مكان ما، على الرغم من أن المحللين يقللون من هذا المخاطر، ويمكن القول أن المطورين قادرون على نسيان تغيير السياق المتزامن بنفس القدر.

وثانياً، يأتي الميزة النادرة إلى حد ما من عدم تضمين اختيار التقاط السياق المتزامن أو عدم تضمينه في جميع الطرق. بمعنى آخر، قد أرغب في تشغيل الطريقة “X” مع سياق متزامن في حالة، بينما قد أرغب في تشغيل نفس الطريقة دون واحد في حالة أخرى. عندما يكون “ConfigureAwait(false)” مدمجًا في كل مكان، فإن هذا غير ممكن. ومع ذلك، هذا المطلب نادر الحدوث إلى حد ما، ولكن قد يواجه المرء حاجة لهذا النوع من التعديلات أحيانًا، كما حدث في Npgsql.

باختصار، على الرغم من أن تعيين السياق المتزامن مرة واحدة يبدو وكأنه يوفر نفس التأثير كما “ConfigureAwait(false)” في نقل العمل عن سياق المتزامن، إلا أنه يأتي بتجربة قراءة أكثر وضوحًا وقدرة نادرة على التحكم في التقاط السياق في المستويات الدقيقة.

ثالثًا، ينبغي أن ننظر إلى الأداء. في الغالب، لن يؤدي تعيين السياق المتزامن إلى تحسين أداء التطبيق بشكل كبير، لكن قد يكون هناك بعض الفوارق الطفيفة في الأداء بين النهجين. على سبيل المثال، عند استخدام “ConfigureAwait(false)”، يُمكن أن يؤدي ذلك إلى توفير موارد الخيوط (threads) في تطبيق ASP.NET الخاص بك، حيث أنه سيقوم بتحرير الخيط المستخدم في وقت الانتظار للقيام بأعمال أخرى، بينما تقوم بالانتظار على الموارد الخلفية. ومع ذلك، تذكر أن هذه الفروقات في الأداء قد تكون طفيفة وغالبًا ما تكون تبادلًا مقابلًا للوضوح وسهولة الصيانة.

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

في النهاية، القرار بين استخدام “ConfigureAwait(false)” وتعيين السياق المتزامن يعتمد على متطلبات تطبيقك وعلى الميزات التي تهتم بها. إذا كنت تهتم بالوضوح وسهولة الصيانة، فقد يكون تعيين السياق المتزامن مرة واحدة هو الحل المثالي بالنسبة لك. ومع ذلك، إذا كان الأداء مشكلة حيوية، أو إذا كنت تستخدم المكتبة في بيئات معينة تتطلب تحكمًا دقيقًا في السياق، فقد يكون من الأفضل استخدام “ConfigureAwait(false)” بدلاً من ذلك.