تجنُّب عكس الأولوية

توضّح هذه المقالة كيف يحاول نظام الصوت في Android تجنُّب وقلب الأولوية ويسلط الضوء على الأساليب التي يمكنك استخدامها أيضًا

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

خلفية

خادم AudioFlinger لأجهزة Android و AudioTrack/AudioRecord تتم إعادة هيكلة تنفيذ العميل لتقليل وقت الاستجابة. وقد بدأ هذا العمل في الإصدار 4.1 من نظام التشغيل Android، واستمر تقديم المزيد من التحسينات. في 4.2 و4.3 و4.4 و5.0.

ولتحقيق وقت الاستجابة البطيء هذا، لزم الأمر إجراء العديد من التغييرات على مستوى النظام. وَاحِدْ أن التغيير المهم هو تخصيص موارد وحدة المعالجة المركزية للموارد الزمنية سلاسل المحادثات ذات سياسة جدولة أكثر توقعًا جدولة موثوقة يسمح بتقليل أحجام المخزن المؤقت الصوتي وأعداده مع الحفاظ على لتجنب التجاوز والتجاوز.

قلب الأولوية

قلب الأولوية هو وضع إخفاق كلاسيكي لأنظمة الوقت الفعلي، حيث يتم حظر مهمة ذات أولوية أعلى لفترة انتظار غير محددة لمهمة منخفضة الأولوية لإصدار مورد مثل (مشترك دولة محمية بـ) mutex

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

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

في تطبيق الصوت على Android، يكون عكس الأولوية هو حدوثها في هذه الأماكن. ولذا يجب أن تركز انتباهك هنا:

• بين خيوط المزج العادية وسلسلة المزج السريع في AudioFlinger
• بين سلسلة معاودة الاتصال بالتطبيق للحصول على مقطع صوتي سريع سلسلة مزج سريع (لكلاهما أولوية مرتفعة، لكنهما أولويات مختلفة)
• بين سلسلة معاودة الاتصال بالتطبيق للحصول على تسجيل صوتي سريع سلسلة التقاط سريع (مثل التجربة السابقة)
• ضمن تطبيق "طبقة تجريد الأجهزة الصوتية" (HAL)، على سبيل المثال لإلغاء صدى الصوت أو الاتصال الهاتفي
• داخل برنامج تشغيل الصوت في kernel
• بين سلسلة محادثات AudioTrack أو AudioRecord (تسجيل صوتي) وسلاسل محادثات التطبيقات الأخرى (لا نسيطرة على ذلك)

الحلول الشائعة

تشمل الحلول النموذجية ما يلي:

• إيقاف المقاطعات
• مُتجاهلات الاكتساب ذات الأولوية

لا يمكن إيقاف المقاطعات في مساحة مستخدم Linux، لا تعمل مع المعالجات المتماثلة المتعددة (SMP).

اكتساب الأولوية ألعاب فوتكس (متجاهلات مساحة المستخدم السريعة) لا تُستخدم في النظام الصوتي لأنها ذات وزن ثقيل نسبيًا، ولأنّهم يعتمدون على عميل موثوق به

الأساليب المستخدمة بواسطة Android

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

نستخدم أيضًا العمليات البسيطة مثل:

• زيادة
• استخدام البت "or"
• استخدام "and" على البت

كل ذلك يُرجع القيمة السابقة ويتضمن حواجز بروتوكول إدارة المشروعات (SMP). والعيوب هو أنها يمكن أن تتطلب محاولات غير محدودة. من الناحية العملية، وجدنا أن إعادة المحاولة ليست مشكلة.

ملاحظة: العمليات البسيطة وتفاعلاتها مع حواجز الذاكرة يُساء فهمها بشكل سيئ ويتم استخدامها بشكل غير صحيح. نقوم بتضمين هذه الطرق هنا للتأكّد من اكتمال العملية، ولكن أنصحك أيضًا بقراءة المقالة تطبيق SMP Primer لأجهزة Android لمزيد من المعلومات.

لا تزال لدينا معظم الأدوات المذكورة أعلاه ونستخدمها، وقد تم مؤخرًا أضفنا هذه الأساليب:

• استخدام مؤلف فردي ذي قارئ واحد بدون حظر قوائم انتظار FIFO للبيانات.
• يمكنك محاولة نسخة بدلاً من مشاركة الحالة بين ارتفاع و ذات أولوية منخفضة.
• عند الحاجة إلى مشاركة الولاية، يجب قصر الولاية على الحد الأقصى للحجم كلمة التي يمكن الوصول إليها من خلال وحدة نقل واحدة بدون إعادة المحاولة.
• بالنسبة إلى الحالة المعقدة المكونة من عدة كلمات، يمكنك استخدام قائمة انتظار الحالة. قائمة انتظار الولاية هي في الأساس مجرد قاعدة بيانات لمؤلفين فرديين ومؤلفين من قارئ واحد وغير محظور قائمة انتظار مستخدمة للحالة بدلاً من البيانات، باستثناء أنه يتم تصغير الكاتب الدفع المجاورة في دفعة واحدة.
• انتبه لما حواجز الذاكرة للتحقق من صحة SMP.
• الثقة، ثم إثبات الملكية: عند المشاركة الولاية بين العمليات، فلا أن الدولة مكونة بشكل جيد. على سبيل المثال، تحقق من أن المؤشرات تقع ضمن الحدود. عملية التحقّق هذه غير مطلوبة بين سلاسل المحادثات. وفي نفس العملية، بين عمليات الثقة المتبادلة (والتي لها نفس المعرّف الفريد). من غير الضروري أيضًا مشاركة البيانات مثل صوت PCM عندما يكون التلف غير مفهوم.

الخوارزميات التي لا تؤدي إلى الحظر

الخوارزميات التي لا تؤدي إلى الحظر قد كانت موضوع دراسة حديثة إلى حد كبير. ولكن باستثناء قوائم انتظار FIFO لكاتب واحد، وجدنا أنها معقدة وعرضة للخطأ.

بدءًا من الإصدار Android 4.2، يمكنك العثور على عبارات غير دروس للقارئ الواحد/المؤلف الواحد في المواقع الجغرافية التالية:

• frames/av/include/media/nbaio/
• frames/av/media/libnbaio/
• works/av/services/audioflinger/Stateplaylist*

تم تصميم هذه الأدوات خصيصًا لـ AudioFlinger للأغراض العامة. تشتهر الخوارزميات التي لا تمنع الحظر بكونها يصعب تصحيحها. يمكنك اعتبار هذه التعليمة البرمجية نموذجًا. لكن كن أن تكون هناك أخطاء، وأن الفئات لا يمكن ضمان مناسبة لأغراض أخرى.

بالنسبة إلى المطوّرين، يجب تحديث بعض نماذج رمز تطبيق OpenSL ES إلى تستخدم خوارزميات لا تحظر المحتوى أو تشير إلى مكتبة مفتوحة المصدر ليست Android

لقد نشرنا مثالاً على تنفيذ معيار FIFO بدون حظر، وهو مصمّم خصيصًا رمز التطبيق. يمكن الاطّلاع على هذه الملفات المتوفرة في الدليل المصدر للنظام الأساسي frameworks/av/audio_utils:

• include/audio_utils/fifo.h
• fifo.c
• include/audio_utils/roundup.h
• roundup.c

الأدوات

وعلى حد علمنا، لا توجد أدوات تلقائية وإيجاد عكس الأولوية، خاصة قبل حدوثها. بعض الإشعارات تعد أدوات تحليل التعليمة البرمجية الثابتة قادرة على إيجاد الأولوية في حالة القدرة على الوصول إلى قاعدة الرموز بالكامل. بالطبع، إذا استخدام رمز عشوائي للمستخدم (كما هو موضّح في التطبيق) أو قاعدة رموز كبيرة (مثل نواة Linux وبرامج تشغيل الأجهزة)، التحليل الثابت غير عملي. الشيء الأكثر أهمية هو اقرأ التعليمات البرمجية بعناية شديدة وتعرّف جيدًا على للنظام والتفاعلات. أدوات مثل systrace أو ps -t -p مفيدة لرؤية عكس الأولوية بعد حدوثها، لكن لا يخبرك بها مسبقًا.

كلمة أخيرة

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