لقد درسنا تعدد المهام ، خاصية نظام التشغيل لتشغيل العديد من البرامج شبه المستقلة في نفس الوقت. قبل أن نلقي نظرة فاحصة على المهام ، نحتاج إلى التعامل مع الشروط.
المقالات السابقة في السلسلة:
المادة رقم 2. RTOS: البنية ووضع الوقت الحقيقي
المادة رقم 1. RTOS: مقدمة.
نستخدم كلمة "مهمة" ، على الرغم من عدم وجود معنى دقيق لها. المصطلحات الأخرى ، "التدفق" و "العملية" ، أكثر تخصصًا ، ويجب عليك أن تفهم ما تعنيه وكيف تختلف.
تستخدم العديد من أنظمة RTOS المستخدمة في التطبيقات المضمنة نموذجًا متعدد الخيوط. يمكن تنفيذ العديد من سلاسل الرسائل في وقت واحد ، تحتل نفس مساحة العنوان:
وهذا يعني أن تبديل السياق هو ، أولاً وقبل كل شيء ، التبديل من مجموعة تسجيلات المعالج إلى مجموعة أخرى. إنه بسيط وسريع. الخطر المحتمل هو أن كل مؤشر ترابط لديه القدرة على الوصول إلى الذاكرة التي تنتمي إلى مؤشرات الترابط الأخرى أو إلى RTOS نفسها.
البديل هو نموذج العمليات المتعددة. إذا كانت هناك عدة عمليات قيد التشغيل ، فإن كل عملية لها مساحة عنوان خاصة بها ولا يمكنك الوصول إلى الذاكرة المرتبطة بالعمليات الأخرى أو RTOS:
وهذا يجعل تبديل السياق أكثر صعوبة واستهلاكًا للوقت ، حيث يجب على نظام التشغيل تكوين وحدة إدارة الذاكرة بشكل مناسب ، مدير الذاكرة (وحدة إدارة الذاكرة الإنجليزية ، MMU). بالطبع ، هذه البنية ممكنة فقط مع معالج يدعم MMU. يتم دعم العمليات بواسطة نظام التشغيل RTOS "عالي الأداء" ومعظم أنظمة تشغيل سطح المكتب. علاوة على ذلك ، يمكن لكل عملية دعم الانقسام إلى عدة مؤشرات ترابط ، ولكن نادرًا ما يتم استخدام هذه الخاصية في التطبيقات المضمنة العادية.
في حالة توفر MMU ، يمكن الوصول إلى حل وسط:
تدعم العديد من وحدات RTOS "المتدفقة" وحدات MMU لحماية الذاكرة من الوصول غير المصرح به. وهكذا ، بينما تكون المهمة في السياق ، فإن جزءًا فقط من التعليمات البرمجية / البيانات والأقسام الضرورية من RTOS هي "مرئية" ؛ تم تعطيل كتل الذاكرة المتبقية ، وستتسبب محاولة الوصول في حالة طارئة (للأشخاص العاديين) / استثناء (للمبرمجين). هذا يجعل تبديل السياق أكثر صعوبة ، ولكن التطبيق نفسه أكثر أمانًا. يمكن أن يطلق على هذا الوضع "وضع حماية مؤشر الترابط" أو "وضع معالجة خفيف الوزن".
المخططين
كما نعلم ، يتم تحقيق وهم التنفيذ المتزامن للمهام من خلال تخصيص وقت المعالج لإكمال كل مهمة. هذه هي الوظيفة الأساسية للنواة. تسمى طريقة توزيع الوقت بين المهام "التخطيط". المجدول - برنامج يحدد المهمة التالية لنقل التحكم إليها. منطق المجدول والآلية التي تحدد متى وما يجب تنفيذه هو خوارزمية التخطيط. في هذا القسم ، سنلقي نظرة على العديد من خوارزميات التخطيط. يعد تخطيط المهام موضوعًا شاملاً ، ويتم تخصيص العديد من الكتب له. سنوفر الحد الأدنى الضروري لفهم ما يمكن أن يقدمه نظام RTOS معين في هذا الصدد.
تشغيل إلى برنامج جدولة الإنجاز (RTC)
جدولة RTC (تشغيل حتى الاكتمال) بسيطة للغاية وتستهلك الحد الأدنى من الموارد. هذه خدمة مثالية إذا استوفت متطلبات التطبيق. فيما يلي رسم بياني لنظام يستخدم جدولة RTC:
يتناوب المجدول على استدعاء وظائف المستوى الأعلى لكل مهمة. تتحكم المهمة في المعالج (تقاطعه) حتى تقوم وظيفة المستوى الأعلى بتنفيذ عملية الإرجاع. إذا كان RTOS يدعم تعليق المهام ، فلن يتم تنفيذ أي مهام معلقة حاليًا. تمت مناقشة هذا الموضوع في المقالة أدناه ، راجع "إيقاف مهمة مؤقتًا".
ميزة كبيرة لجدولة RTC ، بالإضافة إلى البساطة ، هي رصة واحدة وقابلية الكود (التجميع غير مطلوب). الجانب السلبي هو أن المهمة يمكن أن "تأخذ" المعالج ، لذا فإن التطوير الدقيق للبرنامج مطلوب. على الرغم من حقيقة أنه في كل مرة يتم تنفيذ المهمة من البداية (على عكس جداول المواعيد الأخرى التي تسمح لك ببدء العمل من مكان التوقف) ، يمكنك تحقيق المزيد من المرونة بمساعدة متغيرات "الحالة" الثابتة التي تحدد منطق كل مكالمة لاحقة.
الجدولة المستديرة روبن (RR)
جدولة RR ("دائري") تشبه RTC ، ولكنها أكثر مرونة وبالتالي أكثر تعقيدًا:
ومع ذلك ، في حالة جدولة RR ، لا تحتاج المهمة إلى تنفيذ عبارة الإرجاع في دالة المستوى الأعلى. يمكنها تحرير المعالج في أي وقت عن طريق إجراء مكالمة RTOS. يؤدي هذا الاستدعاء إلى kernel لحفظ سياق المهمة الحالية (جميع التسجيلات ، بما في ذلك مؤشر المكدس ومؤشر الأوامر) وتحميل سياق المهمة التالية في قائمة الانتظار. في بعض أنظمة RTOS ، يمكن تحرير المعالج (إيقاف المهمة مؤقتًا) تحسبًا لتوافر مورد kernel. هذا أكثر تعقيدًا ، لكن المبدأ هو نفسه.
يتم تحديد مرونة جدولة RR من خلال القدرة على الاستمرار في أداء المهام من لحظة التعليق ، دون إجراء تغييرات على رمز التطبيق. من أجل المرونة ، يجب عليك دفع إمكانية نقل أقل للرمز ومكدس منفصل لكل مهمة.
جدولة الشرائح الزمنية (TS)
جدولة TS (شريحة زمنية - "شريحة زمنية") إلى مستوى أكثر تعقيدًا من RR. يتم تقسيم الوقت إلى فتحات (فترات ، شرائح زمنية) ، حيث يمكن تنفيذ كل مهمة ضمن الفاصل الزمني المخصص لها:
بالإضافة إلى القدرة على تحرير المعالج طوعًا ، يمكن مقاطعة المهمة عن طريق استدعاء المجدول الذي يتم تنفيذه بواسطة معالج مقاطعة مؤقت النظام. إن فكرة تعيين فترة زمنية محددة لكل مهمة جذابة للغاية (حيثما أمكن): من السهل فهمها ، ويمكن التنبؤ بها للغاية.
عيب جدولة TS هو أن النسبة المئوية لوقت وحدة المعالجة المركزية المخصصة لكل مهمة قد تختلف ، اعتمادًا على ما إذا كانت المهام الأخرى معلقة وأجزاء أخرى من الفتحات مجانية:
يمكن أن يصبح جدولة TS أكثر قابلية للتنبؤ بها إذا تم تنفيذ المهام في الخلفية. يمكن تنفيذ مهمة الخلفية بدلاً من أي مهمة معلقة وتستغرق الفترة الزمنية عندما يتم تحرير المهمة (أو تتوقف مؤقتًا).
من الواضح أن مهمة الخلفية لا يجب أن تؤدي عملاً حرجًا للوقت ، لأن حصة وقت المعالج المخصص لها غير قابلة للتنبؤ بها تمامًا: لا يمكن تحديد موعدها أبدًا.
يفترض مثل هذا الحل أن كل مهمة يمكن أن تتوقع متى سيتم التخطيط لها مرة أخرى. على سبيل المثال ، إذا كان لديك فتحات لـ 10 مللي ثانية و 10 مهام ، فإن المهمة تعرف أنه إذا تم تحريرها ، فستستمر في التنفيذ بعد 100 مللي ثانية. باستخدام هذا الحل ، يمكنك تحقيق تكوين أكثر مرونة للدورات الزمنية (التوقيتات) لمهام التطبيق.
يمكن أن يوفر نظام RTOS فترات زمنية مختلفة لكل مهمة. وهذا يوفر المزيد من المرونة ، ولكن أيضًا يمكن التنبؤ به كما هو الحال مع حجم فاصل زمني ثابت. خيار آخر هو تخصيص أكثر من فاصل زمني واحد للمهمة نفسها ، إذا كنت بحاجة إلى زيادة نسبة وقت المعالج المخصص.
جدولة الأولويات
تدعم معظم أنظمة RTOS التخطيط القائم على الأولوية. الفكرة بسيطة: يتم إعطاء كل مهمة الأولوية ، وفي أي وقت يتم نقل المهمة التي لها الأولوية القصوى و "جاهزة" للتنفيذ إلى المعالج:
يبدأ المجدول عند وقوع حدث (على سبيل المثال ، مقاطعة أو استدعاء لخدمة kernel محددة) يفرض مهمة ذات أولوية عالية لتصبح "جاهزة". هناك ثلاث حالات يبدأ فيها المجدول في العمل:
• تم تعليق المهمة ؛ يجب على المجدول جدولة المهمة التالية.
• تعد المهمة مهمة ذات أولوية أعلى (باستخدام مكالمة API).
• معالج المقاطعة (روتين مقاطعة الخدمة ، ISR) يعد مهمة ذات أولوية أعلى. يمكن أن يكون هذا معالج مقاطعة لجهاز إدخال / إخراج أو نتيجة جهاز ضبط وقت النظام.
يختلف عدد مستويات الأولوية (من 8 إلى عدة مئات) ، كما تختلف قيم العتبة: ترى بعض أنظمة RTOS أن الأولوية القصوى هي 0 ، بينما تشير قيم أخرى في المستوى 0 إلى الأولوية الأدنى.
تسمح بعض أنظمة RTOS بمهمة واحدة فقط في كل مستوى من مستويات الأولوية ؛ البعض الآخر يسمح بالقليل ، مما يعقد بشكل كبير هياكل البيانات المرتبطة بها. تسمح لك العديد من أنظمة التشغيل بتغيير أولويات المهام في وقت التشغيل ، مما يزيد من تعقيد العمليات.
المجدول المركب
لقد قمنا بفحص العديد من المخططين ، ومع ذلك ، فإن العديد من RTOS التجارية تقدم حلولًا أكثر تعقيدًا تتميز بخصائص العديد من الخوارزميات في وقت واحد. على سبيل المثال ، يمكن لـ RTOS دعم مهام متعددة في كل مستوى من مستويات الأولوية ، ثم استخدام TS لتقسيم الوقت بين العديد من المهام الجاهزة على أعلى مستوى.
حالات المهمة
في أي وقت معين ، يتم تنفيذ مهمة واحدة فقط. بالإضافة إلى الوقت الذي يقضيه المعالج في معالج المقاطعة (المزيد عن هذا في المقالة التالية) أو المجدول ، فإن المهمة "الحالية" هي المهمة التي يتم تنفيذ رمزها حاليًا والتي تتميز بياناتها بقيم التسجيل الحالية. قد تكون هناك مهام أخرى "جاهزة" للإطلاق ، وسيأخذها المجدول في الاعتبار. في نظام RTOS بسيط باستخدام جدولة RTC أو RR أو TS ، هذا كل ما في الأمر. ولكن في كثير من الأحيان ، ودائماً بجدولة أولوية ، يمكن أن تكون المهام في حالة تعليق ، مما يعني أنه لا يتم أخذها في الاعتبار من قبل المجدول حتى يتم استئنافها وتصبح في حالة "استعداد".
أوقف المهمة مؤقتًا
يمكن أن يكون إيقاف المهمة مؤقتًا أمرًا بسيطًا للغاية: تتوقف المهمة مؤقتًا من تلقاء نفسها (عن طريق الاتصال بواجهة برمجة التطبيقات) أو توقفها مهمة أخرى مؤقتًا. من خلال استدعاء API آخر ، يمكن استئناف مهمة معلقة بمهمة أخرى أو معالج المقاطعة. هذا تعليق "غير مشروط" أو "نقي". تطلق بعض أنظمة التشغيل على هذه المهمة "النوم".
يمكن لـ RTOS تزويد المهمة بالقدرة على التوقف (النوم) لفترة معينة من الوقت ، وبعد ذلك يتم استئنافها (وفقًا لساعة النظام). يمكن أن يسمى هذا "النوم".
إذا كان RTOS يدعم "حجب" مكالمات API ، فيمكن استخدام تعليق أكثر تعقيدًا. تسمح هذه المكالمة للمهمة بطلب خدمة أو مورد ستتلقاه على الفور إذا كانت متوفرة. خلاف ذلك ، سيتم تعليقها حتى تصبح متاحة. يمكن أيضًا تحديد المهلات التي يتم فيها استئناف المهمة إذا كان المورد غير متوفر لفترة زمنية معينة.
حالات المهمة الأخرى
يدعم العديد من أنظمة RTOS حالات أخرى ، لكن المفاهيم والتعاريف تختلف بشكل كبير. على سبيل المثال ، الحالة "منتهية" ، وهذا يعني ببساطة أن الوظيفة الخارجية للمهمة قد خرجت (إما عن طريق إرجاع الرمز أو بمجرد استكمال كتلة الوظيفة الخارجية). لكي تبدأ المهمة المكتملة في التشغيل مرة أخرى ، قد تحتاج إلى إعادة تعيينها بطريقة أو بأخرى.
خيار آخر هو حالة إنهاء الخدمة. يشبه هذا التعليق الكامل (خالص) ، باستثناء أنه يجب إعادة تعيين المهمة لإعادة التشغيل.
إذا كان RTOS يدعم الإنشاء الديناميكي وحذف المهام (راجع المقالة التالية) ، فهذا يعني حالة أخرى محتملة للمهمة - "محذوفة".
عندما كنا نعمل على نظام التشغيل OSRV MAX الخاص بنا في الوقت الفعلي (سبق لي أن نشرت مقالات حول هذا الموضوع) ، " صادف فريقنا" مدونة Colin Walls ، الخبيرة في الإلكترونيات الدقيقة والبرامج الثابتة في Mentor Graphics. بدت المقالات مثيرة للاهتمام ، وترجمتها لأنفسهم ، لكن لكي لا "يكتبوا على الطاولة" قرروا نشرها. آمل أن تكون مفيدة لك أيضًا. إذا كان الأمر كذلك ، فنحن نخطط لنشر جميع المقالات المترجمة في السلسلة.
نبذة عن الكاتب: يعمل Colin Walls في صناعة الإلكترونيات لأكثر من ثلاثين عامًا ، ويكرس معظم وقته للبرامج الثابتة. وهو الآن مهندس برامج ثابتة في Mentor Embedded (قسم من Mentor Graphics). غالبًا ما يتحدث كولين وولز في المؤتمرات والندوات ، مؤلف العديد من المقالات الفنية وكتابين عن البرامج الثابتة. يعيش في المملكة المتحدة. مدونة كولين المهنية: blogs.mentor.com/colinwalls ، البريد الإلكتروني: colin_walls@mentor.comيتم نشر المادتين الأولى والثانية من الدورة
هنا.