في عالم تطوير برامج التشغيل وأنظمة التشغيل، تلعب وظائف رد الاتصال (Callbacks) دورًا حيويًا وحساسًا للغاية. هذه الوظائف، التي يتم استدعاؤها استجابة لأحداث نظامية منخفضة المستوى مثل بدء أو إنهاء عملية أو خيط، أو تحميل مكتبة DLL، هي العمود الفقري لاستقرار النظام وأدائه. ولكن مع هذه الأهمية، تأتي مجموعة صارمة من أفضل الممارسات التي غالبًا ما يتم تجاهل جوهرها، مما يؤدي إلى مشكلات خطيرة في الأداء أو حتى تعليق النظام.
لماذا السرعة أمر حاسم: نظرة على أفضل الممارسات
تحدد وثائق مايكروسوفت، في قسم أفضل الممارسات لتنفيذ وظائف رد الاتصال المتعلقة بالعمليات والخيوط، إرشادات واضحة لضمان عمل هذه الوظائف بكفاءة. هذه الإرشادات ليست مجرد توصيات، بل هي متطلبات ضرورية للحفاظ على سلامة النظام.
- اجعل الإجراءات الروتينية قصيرة وبسيطة: يجب أن تكون وظائف رد الاتصال سريعة التنفيذ وتؤدي مهامها الأساسية فقط.
- لا تقم بإجراء مكالمات لخدمات وضع المستخدم للتحقق من صحة العملية، الخيط، أو الصورة: تجنب التفاعل مع وضع المستخدم مباشرة من رد الاتصال.
- لا تقم بإجراء مكالمات التسجيل: تجنب العمليات التي قد تتسبب في تأخير أو حظر.
- لا تقم بإجراء مكالمات دالة للحظر و/أو الاتصال بين العمليات (IPC): يجب ألا تقوم وظيفة رد الاتصال بحظر سير العمل.
- لا تقم بالمزامنة مع سلاسل رسائل أخرى: لأن ذلك قد يؤدي إلى حالة توقف تام لإعادة الدخول.
تشير هذه المحاذير بوضوح إلى أن وظائف رد الاتصال يتم استدعاؤها في لحظات حرجة من دورة حياة النظام. إذا استغرقت هذه الوظائف وقتًا طويلاً، فإنها تبطئ النظام بأكمله. تشير المتطلبات الصارمة، مثل تجنب مكالمات التسجيل، إلى أنها قد تُستدعى بينما يحتفظ النظام بأقفال داخلية حساسة، مما يجعل أي تأخير كارثيًا.
فهم روح القاعدة لا نصها: مخاطر التفسير الخاطئ
تستمر قائمة أفضل الممارسات بتقديم حل للعمليات المعقدة، حيث تنص على:
- استخدم خيوط عامل النظام (System Worker Threads) لجدولة العمل الخاص الذي يتضمن:
- واجهات برمجة التطبيقات البطيئة أو واجهات برمجة التطبيقات التي تستدعي عملية أخرى.
- أي سلوك حظر قد يؤدي إلى مقاطعة سلاسل الرسائل في الخدمات الأساسية.
هذا الاقتراح يقدم طريقة لتفريغ العمل المكلف إلى كود يعمل خارج سياق رد الاتصال، مما يؤكد مرة أخرى على ضرورة أن يكون رد الاتصال نفسه سريعًا وبأقل قدر من الحظر. ومع ذلك، غالبًا ما يواجه خبراء دعم المؤسسات حالات يكون فيها سبب تعليق النظام هو انتهاك برنامج تشغيل للقاعدة القائلة بأن رد الاتصال يجب أن يعود بسرعة.
المثال الأكثر شيوعًا هو برنامج التشغيل الذي يتبع التوجيهات بوضع العمل في قائمة انتظار إلى خيط عامل النظام، ولكنه بعد ذلك يقوم بالحظر (Blocking) في انتظار اكتمال هذا العمل. هذه حالة يتم فيها اتباع القواعد حرفيًا دون فهم السبب الجوهري لوجودها.
القاعدة الأساسية هي أن رد الاتصال يجب أن يكون سريعًا ويعود بسرعة. قد يفسر السائق نص القانون حرفيًا، حيث يفوض العمل إلى خيط عامل النظام، ولا توجد قاعدة صريحة تقول ‘لا تنتظر عناصر العمل’. ولكن القواعد التي تحظر ‘مكالمات الحظر’ و’المزامنة مع سلاسل رسائل أخرى’ توضح أن رد الاتصال لا يجب أن يُحظر لفترات طويلة.
التوثيق المعدّل وتوضيح الغموض
يبدو أنه تم تحديث وثائق مايكروسوفت في عام 2020 لمعالجة هذه الحالة المحددة، حيث أضافت:
- إذا كنت تستخدم خيوط عامل النظام، فلا تنتظر حتى يكتمل العمل. يؤدي القيام بذلك إلى إبطال الغرض من وضع العمل في قائمة الانتظار لإكماله بشكل غير متزامن.
قد يجادل البعض بأن هذه القاعدة مشمولة بالفعل بقاعدة ‘عدم المزامنة مع سلاسل رسائل أخرى’. ولكن المطور قد يفسر ذلك قائلاً: ‘أنا لا أقوم بالمزامنة مع خيط آخر. أنا أقوم بالمزامنة مع حدث!’، متناسيًا أن الحدث يتم تعيينه بواسطة خيط آخر، مما يعني أنه تتم المزامنة بشكل فعال مع خيط آخر. هذا يشبه العذر ‘لم يكن أنا، بل كان أخي’، حيث يتم الالتفاف على القاعدة بطرق تبدو تقنية ولكنها تتعارض مع نيتها الحقيقية.
نحو توثيق أكثر وضوحًا وفعالية
لتحسين الوضوح، يمكن أن تبدأ وثائق أفضل الممارسات بتعريف شامل يوضح جوهر المتطلبات، مثل:
وظيفة رد الاتصال يجب أن تؤدي عملها بسرعة دون حظر. إذا كنت بحاجة إلى القيام بعمل معقد أو المزامنة مع خيوط أو عمليات أخرى، فقم بتنفيذ العمل بشكل غير متزامن، على سبيل المثال باستخدام خيوط عامل النظام.
بعد ذلك، يمكن تقديم قائمة بأمثلة محددة للأشياء التي تعتبر حظرًا غير مسموح به، متبوعة بقيود إضافية لضمان عدم وجود مجال للتفسير الخاطئ.
إن فهم الأساس المنطقي وراء القواعد، وليس مجرد اتباع نصها، هو ما يميز المطورين المهرة ويضمن بناء أنظمة قوية ومستقرة. في عالم تطوير النواة الحساس، لا يمكن التهاون في هذا المبدأ.