प्राथमिकता उलटने से बचें

यह आलेख बताता है कि कैसे एंड्रॉइड का ऑडियो सिस्टम प्राथमिकता व्युत्क्रमण से बचने का प्रयास करता है, और उन तकनीकों पर प्रकाश डालता है जिनका आप भी उपयोग कर सकते हैं।

ये तकनीकें उच्च-प्रदर्शन ऑडियो ऐप्स, ओईएम और एसओसी प्रदाताओं के डेवलपर्स के लिए उपयोगी हो सकती हैं जो ऑडियो एचएएल लागू कर रहे हैं। कृपया ध्यान दें कि इन तकनीकों को लागू करने से गड़बड़ियों या अन्य विफलताओं को रोकने की गारंटी नहीं है, खासकर यदि ऑडियो संदर्भ के बाहर उपयोग किया जाता है। आपके परिणाम भिन्न हो सकते हैं, और आपको अपना मूल्यांकन और परीक्षण स्वयं करना चाहिए।

पृष्ठभूमि

विलंबता को कम करने के लिए एंड्रॉइड ऑडियोफ्लिंगर ऑडियो सर्वर और ऑडियोट्रैक/ऑडियोरिकॉर्ड क्लाइंट कार्यान्वयन को फिर से आर्किटेक्चर किया जा रहा है। यह कार्य Android 4.1 में शुरू हुआ और 4.2, 4.3, 4.4 और 5.0 में और सुधारों के साथ जारी रहा।

इस कम विलंबता को प्राप्त करने के लिए, पूरे सिस्टम में कई बदलावों की आवश्यकता थी। एक महत्वपूर्ण परिवर्तन सीपीयू संसाधनों को अधिक पूर्वानुमानित शेड्यूलिंग नीति के साथ समय-महत्वपूर्ण थ्रेड्स को निर्दिष्ट करना है। विश्वसनीय शेड्यूलिंग ऑडियो बफ़र आकार और गिनती को कम करने की अनुमति देती है, साथ ही अंडररन और ओवररन से भी बचती है।

प्राथमिकता उलटा

प्राथमिकता व्युत्क्रमण वास्तविक समय प्रणालियों का एक क्लासिक विफलता मोड है, जहां एक उच्च-प्राथमिकता वाले कार्य को असीमित समय के लिए अवरुद्ध कर दिया जाता है, कम-प्राथमिकता वाले कार्य के लिए एक संसाधन जैसे कि म्यूटेक्स (साझा राज्य द्वारा संरक्षित) को जारी करने की प्रतीक्षा की जाती है।

एक ऑडियो सिस्टम में, प्राथमिकता व्युत्क्रम आम तौर पर एक गड़बड़ी (क्लिक, पॉप, ड्रॉपआउट), सर्कुलर बफ़र्स का उपयोग करने पर बार-बार ऑडियो , या किसी कमांड का जवाब देने में देरी के रूप में प्रकट होता है।

प्राथमिकता व्युत्क्रमण के लिए एक सामान्य समाधान ऑडियो बफ़र आकार को बढ़ाना है। हालाँकि, यह विधि विलंबता बढ़ाती है और समस्या को हल करने के बजाय केवल छिपाती है। जैसा कि नीचे देखा गया है, प्राथमिकता व्युत्क्रम को समझना और रोकना बेहतर है।

एंड्रॉइड ऑडियो कार्यान्वयन में, प्राथमिकता व्युत्क्रमण इन स्थानों पर होने की सबसे अधिक संभावना है। और इसलिए आपको अपना ध्यान यहां केंद्रित करना चाहिए:

  • AudioFlinger में सामान्य मिक्सर थ्रेड और तेज़ मिक्सर थ्रेड के बीच
  • तेज़ ऑडियोट्रैक और तेज़ मिक्सर थ्रेड के लिए एप्लिकेशन कॉलबैक थ्रेड के बीच (उन दोनों की प्राथमिकताएं ऊंची हैं, लेकिन थोड़ी अलग प्राथमिकताएं हैं)
  • तेज़ ऑडियो रिकॉर्ड और तेज़ कैप्चर थ्रेड के लिए एप्लिकेशन कॉलबैक थ्रेड के बीच (पिछले के समान)
  • ऑडियो हार्डवेयर एब्स्ट्रैक्शन लेयर (एचएएल) कार्यान्वयन के भीतर, उदाहरण के लिए टेलीफोनी या इको रद्दीकरण के लिए
  • कर्नेल में ऑडियो ड्राइवर के भीतर
  • ऑडियोट्रैक या ऑडियोरिकॉर्ड कॉलबैक थ्रेड और अन्य ऐप थ्रेड के बीच (यह हमारे नियंत्रण से बाहर है)

सामान्य समाधान

विशिष्ट समाधानों में शामिल हैं:

  • व्यवधानों को अक्षम करना
  • प्राथमिकता विरासत म्यूटेक्स

लिनक्स उपयोगकर्ता स्थान में इंटरप्ट को अक्षम करना संभव नहीं है, और सिमेट्रिक मल्टी-प्रोसेसर (एसएमपी) के लिए काम नहीं करता है।

प्रायोरिटी इनहेरिटेंस फ़्यूटेक्स (तेज़ उपयोगकर्ता-स्पेस म्यूटेक्स) का उपयोग ऑडियो सिस्टम में नहीं किया जाता है क्योंकि वे अपेक्षाकृत भारी होते हैं, और क्योंकि वे एक विश्वसनीय क्लाइंट पर भरोसा करते हैं।

Android द्वारा उपयोग की जाने वाली तकनीकें

प्रयोग "ट्राई लॉक" और टाइमआउट के साथ लॉक के साथ शुरू हुए। ये म्यूटेक्स लॉक ऑपरेशन के नॉन-ब्लॉकिंग और बाउंडेड ब्लॉकिंग वेरिएंट हैं। टाइमआउट के साथ लॉक और लॉक का प्रयास काफी अच्छी तरह से काम करता है लेकिन कुछ अस्पष्ट विफलता मोड के लिए अतिसंवेदनशील थे: यदि क्लाइंट व्यस्त होता है तो सर्वर को साझा स्थिति तक पहुंचने में सक्षम होने की गारंटी नहीं थी, और यदि संचयी टाइमआउट बहुत लंबा हो सकता है असंबंधित तालों का एक लंबा क्रम था जो सभी समयबाह्य हो गए।

हम परमाणु परिचालनों का भी उपयोग करते हैं जैसे:

  • वेतन वृद्धि
  • बिटवाइज़ "या"
  • बिटवाइज़ "और"

ये सभी पिछला मान लौटाते हैं और आवश्यक एसएमपी बाधाएं शामिल करते हैं। नुकसान यह है कि उन्हें असीमित पुनर्प्रयास की आवश्यकता हो सकती है। व्यवहार में, हमने पाया है कि पुनः प्रयास कोई समस्या नहीं है।

ध्यान दें: परमाणु संचालन और स्मृति बाधाओं के साथ उनकी अंतःक्रिया को बेहद गलत तरीके से समझा जाता है और गलत तरीके से उपयोग किया जाता है। हम संपूर्णता के लिए इन विधियों को यहां शामिल करते हैं लेकिन अनुशंसा करते हैं कि आप अधिक जानकारी के लिए एंड्रॉइड के लिए एसएमपी प्राइमर लेख भी पढ़ें।

हमारे पास अभी भी उपरोक्त अधिकांश उपकरण हैं और उनका उपयोग करते हैं, और हाल ही में इन तकनीकों को जोड़ा है:

  • डेटा के लिए नॉन-ब्लॉकिंग सिंगल-रीडर सिंगल-राइटर FIFO कतारों का उपयोग करें।
  • उच्च और निम्न-प्राथमिकता वाले मॉड्यूल के बीच स्थिति साझा करने के बजाय स्थिति की प्रतिलिपि बनाने का प्रयास करें।
  • जब राज्य को साझा करने की आवश्यकता होती है, तो राज्य को अधिकतम आकार के शब्द तक सीमित करें जिसे बिना पुनः प्रयास किए एक-बस संचालन में परमाणु रूप से एक्सेस किया जा सकता है।
  • जटिल बहु-शब्द स्थिति के लिए, राज्य कतार का उपयोग करें। एक राज्य कतार मूल रूप से केवल एक गैर-अवरुद्ध एकल-पाठक एकल-लेखक फीफो कतार है जिसका उपयोग डेटा के बजाय राज्य के लिए किया जाता है, सिवाय इसके कि लेखक एक ही धक्का में आसन्न धक्का को ध्वस्त कर देता है।
  • एसएमपी शुद्धता के लिए मेमोरी बाधाओं पर ध्यान दें।
  • विश्वास करें लेकिन सत्यापित कर लें । प्रक्रियाओं के बीच स्थिति साझा करते समय, यह न मानें कि स्थिति अच्छी तरह से बनी हुई है। उदाहरण के लिए, जांचें कि सूचकांक सीमा के भीतर हैं। एक ही प्रक्रिया में थ्रेड्स के बीच, आपसी भरोसेमंद प्रक्रियाओं (जिनमें आमतौर पर एक ही यूआईडी होती है) के बीच इस सत्यापन की आवश्यकता नहीं होती है। यह पीसीएम ऑडियो जैसे साझा डेटा के लिए भी अनावश्यक है जहां भ्रष्टाचार अप्रासंगिक है।

गैर-अवरुद्ध एल्गोरिदम

नॉन-ब्लॉकिंग एल्गोरिदम हालिया अध्ययन का विषय रहा है। लेकिन एकल-पाठक एकल-लेखक फीफो कतारों के अपवाद के साथ, हमने उन्हें जटिल और त्रुटि-प्रवण पाया है।

एंड्रॉइड 4.2 से शुरू करके, आप इन स्थानों पर हमारी गैर-अवरुद्ध, एकल-पाठक/लेखक कक्षाएं पा सकते हैं:

  • फ्रेमवर्क/एवी/शामिल/मीडिया/एनबीएओ/
  • फ्रेमवर्क/एवी/मीडिया/libnbaio/
  • फ्रेमवर्क/एवी/सेवाएं/ऑडियोफ्लिंगर/स्टेटक्यू*

ये विशेष रूप से AudioFlinger के लिए डिज़ाइन किए गए थे और सामान्य प्रयोजन के नहीं हैं। गैर-अवरुद्ध एल्गोरिदम डिबग करने में कठिनाई के लिए कुख्यात हैं। आप इस कोड को एक मॉडल के रूप में देख सकते हैं। लेकिन सावधान रहें, इसमें बग हो सकते हैं, और कक्षाओं के अन्य उद्देश्यों के लिए उपयुक्त होने की गारंटी नहीं है।

डेवलपर्स के लिए, कुछ नमूना ओपनएसएल ईएस एप्लिकेशन कोड को गैर-अवरुद्ध एल्गोरिदम का उपयोग करने या गैर-एंड्रॉइड ओपन सोर्स लाइब्रेरी का संदर्भ देने के लिए अद्यतन किया जाना चाहिए।

हमने एक उदाहरण गैर-अवरुद्ध फीफो कार्यान्वयन प्रकाशित किया है जो विशेष रूप से एप्लिकेशन कोड के लिए डिज़ाइन किया गया है। प्लेटफ़ॉर्म स्रोत निर्देशिका frameworks/av/audio_utils में स्थित इन फ़ाइलों को देखें:

औजार

जहां तक ​​हमारी जानकारी है, प्राथमिकता व्युत्क्रमण का पता लगाने के लिए कोई स्वचालित उपकरण नहीं हैं, खासकर ऐसा होने से पहले। यदि संपूर्ण कोडबेस तक पहुंचने में सक्षम हैं तो कुछ शोध स्थैतिक कोड विश्लेषण उपकरण प्राथमिकता व्युत्क्रम खोजने में सक्षम हैं। बेशक, यदि मनमाना उपयोगकर्ता कोड शामिल है (जैसा कि यहां एप्लिकेशन के लिए है) या एक बड़ा कोडबेस है (लिनक्स कर्नेल और डिवाइस ड्राइवरों के लिए), तो स्थैतिक विश्लेषण अव्यावहारिक हो सकता है। सबसे महत्वपूर्ण बात यह है कि कोड को बहुत ध्यान से पढ़ें और पूरे सिस्टम और इंटरैक्शन पर अच्छी पकड़ हासिल करें। सिस्ट्रेस और ps -t -p जैसे उपकरण प्राथमिकता व्युत्क्रमण होने के बाद उसे देखने के लिए उपयोगी होते हैं, लेकिन आपको पहले से नहीं बताते हैं।

एक अंतिम शब्द

इस सारी चर्चा के बाद, म्यूटेक्स से डरो मत। जब सामान्य गैर-समय-महत्वपूर्ण उपयोग के मामलों में सही ढंग से उपयोग और कार्यान्वित किया जाता है, तो म्यूटेक्स सामान्य उपयोग के लिए आपके मित्र होते हैं। लेकिन उच्च और निम्न-प्राथमिकता वाले कार्यों के बीच और समय-संवेदनशील प्रणालियों में म्यूटेक्स से परेशानी होने की संभावना अधिक होती है।