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

سیستم‌عامل بی‌درنگ بر پایه Unix که توسط شرکت LynuxWorks ارائه می‌شود. این سیستم عامل منطبق با استاندارد POSIX و سازگار با Linux می‌باشد و دارای ویژگی چند نخی است و برای کاربردهای بلادرنگ پیجیده ای که نیاز به پاسخگویی‌های سریع و قطعی دارند، طراحی شده‌است. نوعی سیستم‌عامل است که در آن، زمان، پارامتر کلیدی است. برای مثال در سیستم‌های کنترل فرایند، رایانه‌های بی‌درنگ باید داده‌های فرایند تولید را جمع‌آوری کرده و به کمک آن ماشین‌های داخل کارخانه را کنترل کنند. خیلی اوقات باید فرجه زمانی (deadline) به‌طور دقیق برآورده شود؛ یعنی باید کارها در لحظات خاصی از زمان انجام گیرد. برای مثال اگر یک خودرو در خط مونتاژ در حال حرکت باشد و ربات جوشکاری خیلی زود یا خیلی دیر جوش دهد، خودرو خراب خواهد شد.
زمانی از یک سیستم بی‌درنگ استفاده می‌شود که لازم باشد عملیات پردازنده یا جریان داده در زمان کاملاً مشخصی انجام شود؛ بنابراین یک سیستم بی‌درنگ اغلب به‌عنوان ابزار کنترلی در یک کاربرد خاص استفاده می‌شود. سیستم‌هایی که آزمایش‌های علمی را کنترل می‌کنند، سیستم‌های تصویربرداری پزشکی، سیستم‌های کنترل صنعتی، و نیز برخی از موتورهای انژکتوری در خودرو، کنترلرهای لوازم خانگی و سیستم‌های جنگ‌افزاری، سیستم‌های بی‌درنگ هستند. این سیستم‌ها برای آنکه به‌درستی کار کنند باید پاسخ درست را در فرجه زمانی از پیش تعیین شده بازگردانند در صورتی که در سیستم‌های اشتراک زمانی مطلوب است (ولی اجباری نیست) که سریع پاسخ دهند.

ارتباطات میان‌وظیفه‌ای و به اشتراک گذاری منابع

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

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

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

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

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

پیغام عبور

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

مدیر وقفه ها و برنامه‌ریز

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

تخصیص حافظه

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