تكرار السؤال: …
الإجابة المختصرة
يوجه المحرك بعدم العودة إلى نفس الـ SynchronizationContext الأصلي بعد انتهاء الـ await؛ وكان يمنع الـ Deadlocks في تطبيقات واجهات المستخدم والمكتبات.
الشرح
في بيئات مثل WPF أو ASP.NET الكلاسيكي، كان يوجد SynchronizationContext يفرض تنفيذ ما بعد await على نفس الخيط الأساسي. إذا استخدم كود متزامن .Result، واستدعى الكود الداخلي await، فإنه ينتظر الخيط الأساسي المحجوز مسبقاً وتحدث Deadlock. كتابة ConfigureAwait(false) تتيح استئناف التنفيذ على أي خيط متاح من الـ ThreadPool. في ASP.NET Core الحديث، أُلغي الـ SynchronizationContext تماماً، لكن يظل استخدام ConfigureAwait(false) ممارسة مثالية وموصى بها في كتابة المكتبات العامة (Class Libraries).
مثال بالكود
// في المكتبات المشتركة:
await httpClient.GetStringAsync(url).ConfigureAwait(false);أخطاء شائعة
- الاعتقاد بأن عدم كتابة ConfigureAwait(false) في ASP.NET Core سيسبب Deadlock؛ الـ SynchronizationContext غير موجود أصلاً في ASP.NET Core.