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

از ویکی‌پدیا، دانشنامهٔ آزاد
(تغییرمسیر از سیستم عامل بی درنگ)

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

زمانی از یک سیستم بی‌درنگ استفاده می‌شود که لازم باشد عملیات پردازنده یا جریان داده در زمان کاملاً مشخصی انجام شود؛ بنابراین یک سیستم بی‌درنگ اغلب به‌عنوان ابزار کنترلی در یک کاربرد خاص استفاده می‌شود. سیستم‌هایی که آزمایش‌های علمی را کنترل می‌کنند، سیستم‌های تصویربرداری پزشکی، سیستم‌های کنترل صنعتی، و نیز برخی از موتورهای انژکتوری در خودرو، کنترلرهای لوازم خانگی و سیستم‌های جنگ‌افزاری، سیستم‌های بی‌درنگ هستند. این سیستم‌ها برای آنکه به‌درستی کار کنند باید پاسخ درست را در فرجه زمانی از پیش تعیین شده بازگردانند در صورتی که در سیستم‌های اشتراک زمانی مطلوب است (ولی اجباری نیست) که سریع پاسخ دهند.[۲]

فلسفه طراحی[ویرایش]

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

‫‬مشخصات سیستم عامل‌های بی‌درنگ[ویرایش]

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

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

زمان‌بندی[ویرایش]

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

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

الگوریتم‌ها[ویرایش]

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

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

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

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

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

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

انحصار متقابل[ویرایش]

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

پیغام عبور[ویرایش]

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

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

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

تخصیص حافظه[ویرایش]

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

جستارهای وابسته[ویرایش]

منابع[ویرایش]

  1. Tanenbaum, Andrew S (2008). "Chapter 1, Introduction". Modern Operating Systems (به انگلیسی) (۳ ed.). Pearson/Prentice Hall. p. ۳۴.
  2. Silberschatz, Abraham; Galvin, Peter Baer; Gagne, Greg (2013). "Chapter 1, Introduction". Operating System Concepts (به انگلیسی) (۹ ed.). .John Wiley & Sons, Inc. p. ۴۳.
  3. Phraner, Ralph A. (Fall 1984). "The Future of Unix on the IBM PC". BYTE. pp. 59–64.