سیستم‌عامل بی‌درنگ

• طراحی بر اساس اولویت ـ در این طراحی تنها زمانی وظیفه ای تعویض می‌شود که وظیفه ای با اولویت بالاتر درخواست دهد، به این نوع طراحی را اولویت اولیه نیز می‌نامند.
• طراحی اشتراک زمانی ـ در این طراحی وظیفه بر اساس وقفه ساعت تعویض می‌شود که در رویدادها Round Robin نامیده می‌شود.

سیستم عامل‌های بی‌درنگ را می‌توان با داشتن ملزومات یگانه در پنج حوزه عمومی زیر، مشخص نمود:

• قطعی بودن
• پاسخ دهی
• کنترل کاربر
• قابلیت اطمینان
• نرمش با خطا

سیستم عاملی قطعی است که عملیات خود را در زمان‌های ثابت یا فواصل زمانی از پیش تعیین شده انجام دهد. وقتی چند فرآیند در رقابت برای منابع و زمان پردازنده هستند، هیچ سیستمی نمی‌تواند قطعی باشد. در یک سیستم بی‌درنگ، درخواست‌های فرآیند برای خدمت توسط رخدادها،اولا به سرعتی که می‌تواند به وقفه‌ها پاسخ دهد و ثانیا به اینکه آیا سیستم ظرفیت کافی برای اداره تمام درخواست‌ها، در زمان معلوم را دارد یا خیر، وابسته است. یک معیار مفید برای قابلیت عملکرد قطعی سیستم عامل، حداکثر تأخیر از زمان ورود یک وقفه دستگاه با اولویت بالا، تا زمان شروع خدمت است. در سیستم عامل‌های غیربی‌درنگ این تأخیر ممکن است در محدوده ده تا صدها میلی ثانیه باشد، در حالی که در یک سیستم عامل بی‌درنگ ممکن است این تأخیر حد بالایی از حدود چند میکرو ثانیه تا یک میلی ثانیه باشد. یک مشخصه مربوط ولی مجزا، پاسخ دهی است.قطعی بودن دربارهٔ این است که سیستم عامل قبل از تصدیق، چه مدت صرف خدمت دادن به وقفه می‌نماید. قطعی بودن و پاسخ دهی به همراه هم، زمان پاسخ به رخدادهای خارجی را تعیین می‌کنند ویژگی زمان پاسخ در سیستم‌های بی‌درنگ بسیار حساس است، زیرا چنین سیستم‌هایی باید نیازهای زمانی اعمال شده توسط افراد، دستگاه‌ها و جریان داده‌ها در خارج از سیستم را رعایت کنند. عموما کنترل کاربر در یک سیستم بی‌درنگ بسیار وسیع تر از کنترل کاربرد در سیستم عامل عادی است. در سیستم عامل‌های عادی کاربر یا هیچ گونه کنترلی بر عمل زمان بندی ندارد رهنمودهای کلی ارائه کند ولی در یک سیستم بی‌درنگ لازم است به کاربر اجازه کنترل دقیق اولویت وظیفه داده شود و بتواند میان وظیفه‌های سخت و نرم تفاوت قائل شود. قابلیت اطمینان نوعا در سیستم‌های بی‌درنگ بسیار مهم تر از سیستم‌های عادی است. یک خرابی گذرا در سیستم بی‌درنگ ممکن است تا تعمیر یا تعویض، منجر به سطح خدمت پایین تر گردد. ولی در سیستم بی‌درنگ که در حال پاسخ دهی و کنترل رخدادها در زمان حقیقی است، از دست رفتن با کاهش کارآمدی یک پردازنده می‌تواند عواقب فاجعه آمیزی داشته باشد.

به‌طور کلی وظایف یک دستگاه، سه حالت دارند:

• آماده اجرا – وقتی وظیفه ای تمام منابع و پیش فرض‌های لازم برای اجرا را دارد اما هنوز اجرا نشده‌است، آماده اجرا نام می‌گیرد. در واقع این حالت نقطه شروع قبل از اجرا می‌باشد.
• در حال اجرا – این حالت به وظایفی اطلاق می‌شود که در حال انجام و پیاده‌سازی هستند.
• مسدود – وقتی یک وظیفه منابع و پیش فرض‌های کافی برای اجرا را در اختیار نداشته باشد، در حالت مسدود قرار می‌گیرد.

الگوریتم‌ها

برخی از الگوریتم‌های RTOS عبارتند از :

• زمان‌بندی همکارانه
• زمان‌بندی پیشگیرانه
• برنامه‌ریزی نرخ مونوتیک
  • زمان‌بندی نوبت گردشی
  • زمان‌بندی پیشگیرانه اولویت اولی، پیاده‌سازی پیشگیرانه
  • زمان‌بندی اولویت محور با پیشگیری دیرفرست
  • زمان‌بندی اولویت محور غیرقابل پیشگیری
  • زمانبندی نقطه بحرانی پیشگیرانه
  • زمانبندی ثابت
• راهبرد اولین ضرب العجل زودتر(EDF)
• گراف جهت‌دار تصادفی با گراف چند نخی گذرگاه

این سیستم عامل اساساً در سیستم‌های جاسازی شده بی‌درنگ، در کاربردهایی مانند ارتباطات فضایی و فضانوردی، سیستم‌های نظامی، کنترل فرایند تولید و مخابرات استفاده می‌شود. این سیستم عامل دارای 512 سطح الویت می‌باشد. یک سیستم عامل چند کاره مانند Unix در وظایف بی‌درنگ ضعیف است. برنامه زمانبندی بالاترین اولویت را به کارهایی با کمترین تقاضا در رایانه می‌دهد، بنابراین هیچ راهی برای اطمینان از این که کار مهم و حیاتی دسترسی به منابع کافی دارد، وجود ندارد. سیستم‌های چندکاره باید داده‌های به اشتراک گذاری شده و منابع سخت افزاری را در بین کارهای مختلف مدیریت کنند. این برای دو وظیفه که به‌طور همزمان دسترسی به داده‌های خاص یا منابع سخت افزاری داشته باشند نا امن است. . سه روش معمول برای حل این مشکل وجود دارد:

وقفه موقتی/ غیر فعال کردن وقفه‌ها

سیستم عامل‌های عمومی به‌طور معمول به کاربر برنامه‌ها اجازه نمی‌دهد که وقفه را مسدود کند، زیرا کاربر برنامه می‌تواند تا زمانی که بخواهد CPU را کنترل کند. بعضی از پردازنده‌های مدرن کد حالت کاربر، اجازه نمی‌دهند که وقفه‌ها را غیر فعال کنند زیرا این کنترل یک منبع سیستم عامل کلیدی محسوب می‌شود. با این حال، بسیاری از سیستم‌های جاسازی شده و RTOSها، اجازه می‌دهند که برنامه خود را در حالت هسته برای کارایی بیشتر سیستم تماس اجرا کند و همچنین اجازه دهد برنامه به کنترل بیشتری از محیط عامل بدون نیاز به مداخله سیستم عامل بپردازد. در سیستم‌های تک پردازنده، یک برنامه در حال اجرا در حالت هسته و وقفه‌های پنهانی، کمترین روش سرریز، برای جلوگیری از دسترسی همزمان به یک منبع مشترک،است. در حالی که وقفه‌ها مسدود می‌شوند و کار فعلی تماس OS را مسدود نمی‌کند، کار فعلی استفاده "منحصربفرد" از CPU را دارد، زیرا هیچ کار دیگری یا وقفه نمی‌تواند کنترل را در دست بگیرد، بنابراین بخش بحرانی محافظت می‌شود. هنگامی که وظیفه از بخش بحرانی آن خارج می‌شود، باید وقفه‌ها را پنهان کند؛ در صورت وجود وقفه، به وقفه‌ها پرداخته می‌شود، سپس اجرا خواهد شد. قطع موقت وقفه تنها زمانی انجام می‌شود که طولانی‌ترین مسیر از طریق بخش بحرانی، کوتاه تر از حداکثر وقفه پوشیده مورد نظر باشد . به‌طور معمول این روش حفاظت فقط زمانی استفاده می‌شود که بخش بحرانی تنها چند دستورالعمل باشد و حاوی حلقه نباشد. این روش برای محافظت از ریزپردازنده‌های سخت افزاری ایدئال است که بیت‌ها توسط وظایف مختلف کنترل می‌شوند.

انحصار متقابل

هنگامی که منابع مشترک باید بدون مسدود کردن تمام کارهای دیگر (مانند انتظار برای حافظه فلش تا نوشته شود) رزرو شود، بهتر است از مکانیزم‌های موجود در سیستم عامل‌های عمومی مانند انحصار متقابل و سیستم‌عامل-نظارت‌شده بر پیام‌های متقابل استفاده شود. این مکانیزم‌ها شامل تماس‌های سیستم می‌شوند و معمولاً در هنگام خروج توزیع‌کننده سیستم‌عامل را فراخوانی می‌کنند، بنابراین معمولاً صدها دستورالعمل CPU را برای اجرا درگیر می‌کنند، در حالی که وقفه‌های پنهان می‌تواند به عنوان یک دستورالعمل در برخی از پردازنده‌ها انجام شوند.

پیغام عبور

یکی دیگر از رویکردها برای اشتراک گذاری منابع، برای وظایف ارسال پیام‌ها در یک طرح فرستادن پیام سازماندهی شده‌است. در این پارادایم، منبع تنها با یک وظیفه مستقیما مدیریت می‌شود. وقتی یک کار دیگر می‌خواهد منابع را مورد بازجویی یا دستکاری قرار دهد، یک پیام به کار مدیریتی ارسال می‌کند. اگرچه رفتار زمان-بی‌درنگ آن‌ها شفافیت کمتری از سیستم‌های سمافور دارد، اما سیستم‌های مبتنی بر پیام ساده از بیشتر خطرات پروتکل پرهیز می‌کنند و عموما بهتر از سیستم‌های سمافوره عمل می‌کنند. با این حال، مشکلاتی مانند مشکلات سمافورها ممکن است اتفاق بیفتاد. تداخل اولویت می‌تواند زمانی رخ دهد که یک وظیفه بر روی یک پیام با کمترین اولویت کار کند و پیامی با اولویت بالاتر در صف پیام ورودی خود(یا پیامی که به‌طور غیرمستقیم از یک کار اولویت بالاتر منشا گرفته‌است) نادیده گرفته شود. بن‌بست(علوم‌کامپیوتر)های پروتکل زمانی می‌تواند رخ دهد که دو یا چند وظیفه منتظر یکدیگر برای ارسال پیام‌های پاسخ باشند.

از آنجایی که یک مدیر وقفه وظایف با بالاترین اولویت را مسدود می‌کند و از زمانیکه سیستم عامل‌های بی‌درنگ طراحی شده‌اند تا تأخیر زمانی را به حداقل برسانند، مدیر وقفه معمولاً حد ممکن کوتاه نگه می‌دارد. مدیر وقفه بازپرداخت تمام تعاملات با سخت افزار را در صورت امکان به تأخیر می‌اندازد؛ به‌طور معمول همه چیز لازم است تا وقفه را تأیید یا غیرفعال کند (به طوری که زمانی که مدیریت وقفه انجام می‌شود دوباره رخ نخواهد داد) و یک کار را که باید انجام شود، اعلام کند. این را می‌توان با انحلال یک راننده از طریق رهاسازی سمافور، تنظیم یک پرچم یا ارسال پیام انجام داد. یک زمانبندی اغلب توانایی باز کردن قفل یک کار را از حالت مدیریت وقفه دارد. یک سیستم عامل فهرستی از اشیائی که مدیریت می‌کند مانند موضوعات، انحصار متقابل، حافظه و غیره را نگه می‌دارد. به روز رسانی این کاتالوگ باید به شدت کنترل شود. به همین دلیل زمانی که یک مدیر وقفه یک عملکرد سیستم عامل را در حالی که برنامه در حال انجام شدن است،صدا بزند، می‌تواند مشکل ساز باشد. تابع سیستم‌عامل که توسط یک مدیر وقفه صدا زده می‌شود می‌تواند پایگاه داده شیء را به دلیل بروز رسانی برنامه در یک حالت ناسازگار پیدا کند. دو روش عمده برای حل این مشکل وجود دارد: معماری یکپارچه و معماری بخش. RTOSهایی که معماری یکپارچه را اجرا می‌کنند، به سادگی با قطع کردن وقفه‌ها در هنگام بروز رسانی کاتالوگ داخلی مشکل را حل می‌کنند. کاهش‌یافتنش این است که تأخیر وقفه افزایش می یابد، و به‌طور بالقوه وقفه‌ها از دست می‌روند. معماری جداگانه تماس‌های سیستم‌عامل را مستقیما انجام نمی‌دهد بلکه کار مربوط به سیستم عامل را به یک مدیر جداگانه منتقل می‌کند. این مدیر دارای اولویت بالاتری نسبت به هر موضوع است اما اولویت کمتری نسبت به مدیریت‌وقفه‌ها دارد. مزیت این معماری این است که چندین چرخه برای وقفه تأخیر اضافه می‌کند. در نتیجه، سیستم عامل‌هایی که معماری بخشی(به انگلیسی: segment) را پیاده‌سازی می‌کنند بیشتر قابل پیش‌بینی هستند و می‌توانند در مقایسه با معماری یکپارچه با نرخ وقفه بالاتر مقایسه شوند.

تخصیص حافظه در یک سیستم عامل بی‌درنگ مهم تر از سایر سیستم عامل‌ها است. اولا، برای ثبات نمی‌تواند حافظه نشت کند. (حافظه اختصاص داده شده‌است اما بعد از استفاده آزاد نیست). دستگاه باید، بدون نیاز به یک راه اندازی مجدد به‌طور نامحدود کار کند. به همین دلیل، تخصیص حافظه پویا بر روی آن خنثی می‌شود. هر زمان که امکان‌پذیر باشد، تمام تخصیص حافظه مورد نیاز در زمان کامپایل تعیین شده‌است. دلیل دیگر برای جلوگیری از تخصیص حافظه پویا، تکه تکه شدن حافظه است. با تخصیص مکرر و آزاد شدن توده‌های کوچک حافظه، اتفاقی که ممکن است رخ دهد این است که در آن حافظه موجود به چندین بخش تقسیم شده و RTOS قادر به تخصیص یک حافظه متناوب و به اندازه کافی از حافظه نیست، اگرچه حافظه کافی وجود دارد. ثانیا، سرعت تخصیص مهم است و تخصیص حافظه باید در یک مدت زمان معینی رخ دهد. از آنجا که دیسک‌های مکانیکی زمان پاسخ بسیار طولانی‌تر و غیرقابل پیش‌بینی دارند، مبادله فایل‌های دیسک به دلایل مشابه مثل تخصیص RAM مورد استفاده نمی‌شود. الگوریتم ساده بلوک-سایز-ثابت برای سیستم جاسازی شده به‌علت کم بودن سربار(به انگلیسی:overhead)به خوبی کار می‌کند.

• رایانش بی‌درنگ
• زمانبندی الویت با زودترین ضرب العجل
• زمانبند Rate-monotonic
• سیستم‌عامل روبات