بسياري از كمپاني ها سعي مي كنند Windowse NT را بعنوان يك سيستم عامل استاندارد (OS) در همه سطوح سلسله مراتب صنعتي استفاده كنند . استفاده بعنوان server واضح است ، اما بعضي از مردم مي خواهند كه از آن در سطح كارخانه استفاده كنند . اين درخواستها از رفتار سيستم بي درنگ تقاضا مي شوند .

آيا Windowse NT مي تواند اين نيازها را برآورده سازد ؟
در ابتدا ، ما يك سيستم بي درنگ و مشخصاتي كه سيستم عامل براي تصويب شدن توسط توسعه دهنده نياز دارد را تعريف مي كنيم و همچنين برتري بين سيستم عامل نرم و سخت را تشريح مي كنيم .

در قسمت دوم تشريح مي كنيم كه چگونه و چرا Windowse NT نمي تواند نيازهاي يك سيستم بي درنگ سخت را برآورده سازد .
ما نشان مي دهيم Windowse NT مي تواند تحت شرايط خاصي درخواستهاي يك سيستم عامل بي درنگ نرم و ساده را برآورده سازد .

مقدمه

Windowse NT با نيازهاي يك سيستم عامل بي درنگ طراحي نشده است . آن بعنوان يك سيستم عامل همه منظوره ( GPOS ) طراحي شده است يا به طور مختصر ، بعنوان يك سيستم عامل وابسته به شبكه ( NOS ) .

به خاطر اين كه Windowse NT توسط توسعه دهنده هاي سيستم عامل VMS ساخته شده ، بعضي از مشخصات جهان بي درنگ معرفي شده است . بعنوان مثال Microsoft نظريه طبقه بندي پردازشهاي بي درنگ را ارائه كرد . آنها به يك طريق زمانبندي مي شوند كه آن مي تواند بعنوان يك RTOS باشد . دومين سرويس وقفه ( ISR ) با يك روش كارآمد طراحي شده است .
آيا اين عناصر اجازه مي دهند كه Windowse NT بعنوان يك RTOS طبقه بندي شود ؟

يك سيستم بي درنگ چيست ؟

تعريف :
يك سيستم بي درنگ به ورودي هاي محرك غير قابل پيش بيني با يك روش بهنگام قابل پيش بيني پاسخ مي دهد .
براي انجام آن بعضي نيازهاي اصلي لازم مي شود :
۱ ـ يافتن ضرب العجل . بعد از رخ دادن رويداد يك اقدام در يك زمان محدود و از قبل تعيين شده بايد انجام شود و از بين رفتن زمان ضرب الاجل باعث خطاي نرم افزاري مي شود .

واكنش در مقابل اين فقدان بعنوان يك مشكل اجرايي مطرح مي شود كه مي تواند به وسيله يك پردازنده سريع حل شود . اما اثبات مي شود كه استفاده از يك پردازنده سريع لزوماً مشكل ضرب الاجل را حل نمي كند .
۲ ـ پردازشهاي همزمان : هر وقت بيشتر از يك رويداد به طور همزمان رخ مي دهند ، همه ضرب الاجل ها بايد پاسخ داده شوند . به اين معني است كه يك سيستم بي درنگ مشابهت ذاتي نياز دارد .

كه به وسيله استفاده بيشتر از يك پردازنده سيستم بدست مي آيد . سيستم هاي بي درنگ سخت و نرم :
مي توان سيستمها ي بي درنگ را از يك نظر به دو دسته سخت و نرم تقسيم بندي كرد .
خصوصيات سيستمهاي بي درنگ سخت عبارتند از :
 تحت هيچ شرايطي تاخير پذيرفته نيست .
 اگر تاخير پيش آيد ، نتايج بي فايده اند .

 هزينه گذشتن از ضرب الاجل بي اندازه زياد است .
يك مثال خوب براي سيستم بي درنگ سخت سيستم كنترل چرخهاي هواپيماست .
خصوصيات يك سيستم بي درنگ نرم عبارتند از :
 نتايج تاخير ارزش بيشتري دارند .
 كارآيي پايين تر پذيرش براي تاخير .

بعنوان مثال ماشين Vending و يك زير سيستم شبكه . بسته اي كه توسط يكي از قانون هاي شبكه گم شده را مي توان با درخواست براي دوباره فرستادن آن دوباره بدست آورد . البته با اين كار اجراي سيستم كنترل مي يابد .

نمونه هاي ديگر سيستم هاي بي درنگ كنترل كارخانه نيروي هسته اي ، كنترل ساخت صنعتي ، سيستم هاي تحويل اسلحه ، راهنمايي و هدايت فضايي ، سيستم هاي شناسايي ، كنترل آزمايشات ، آزمايشگاه ، كنترل وسايل ماشين ، روباتها ، سيستم هاي كنترل مسافت سنجي ، كنترل كننده هاي پرينتر ،‌ شكستن ضد قفل ، آژير دزدگير و …
تفاوت بين سيستم هاي بي درنگ سخت و نرم وابسته است به نيازمنديهاي سيستم .
يك سيستم « سخت است اگر » ضرب ا لعجل سيستم نبايد از بين برود .

« و نرم است اگر » ضرب العجل سيستم ON بهتر است كه از بين نرود .
بحثهاي زيادي درباره ارزش دقيق و درست يك سيستم بي درنگ نرم و سخت مطرح است .
مي توان مطرح كرد كه يك سيستم بي درنگ نرم در واقع يك سيستم بي درنگ نيست ،‌ بخاطر اولين نياز : ضرب العجل ازدست رفته . حقيقتاً ، اصطلاح « realtime » اغلب براي اشاره به سيستم سريع ، به طور اشتباه استفاده مي شود .

براي يك سيستم سريع ضرب العجل مي تواند تنظيم شود . پس هم معني با سيستم بي درنگ نرم است . بنابر اين ما مي توانيم يك RTOS ( سيستم عامل بي درنگ ) را بعنوان يك OS ( سيستم عامل ) كه مي تواند براي ساختن يك سيستم بي درنگ سخت استفاده شود.
سيستم عامل بي درنگ سخت يا نرم موجود نيست !

مردم اغلب سيستمهاي بي درنگ را با سيستم عامل هاي بي درنگ اشتباه مي گيرند وحتي ازويژگيهاي سيستمهاي سخت و نرم بد استفاده مي كنند . آنها مي گويند فرضاً اين سيستم Hard RTOS و ديگري Soft RTOS است . در حاليكه درواقع ايندو وجود ندارند . يك RTOS خاص فقط مي تواند به شما اجازه دهد كه يك سيستم بي درنگ سخت را توسعه دهيد .
اما داشتن يك RTOS جلوي توسعه يك سيستمي كه ضرب العجل رانگه نمي دارد را نمي گيرد .

اگر به طور مثال ، شما بخواهيد يك سيستم بي درنگ بسازيد به طوريكه به يك رابطه TCP \ IP واكنش نشان دهد ، آن هيچ وقت يك سيستم بي درنگ سخت نيست . البته اگر شما تصميم بگيريد كه يك درخواست روي سيستم عاملي مثل Windowse 3.11 بسازيد ، سيستم شما هيچ وقت يك سيستم بي درنگ سخت نخواهد بود . همان طور كه رفتار نرم افزار سيستم عامل به طور متوسط قابل پيشگويي نيست .
نيازمنديهاي لازم سيستم عامل بي درنگ ( RTOS ) :

نياز اول : يك RTOS بايد قابل پيش گوئي و Molti thread باشد .
يك RTOS بايد قابل پيشگويي باشد و به اين معني نيست كه يك RTOS بايد سريع باشد . اما بيشترين زماني كه كاري انجام مي دهد بايد سريع باشد و بايد با نيازهاي درخواست شده همساز باشد و Windows 3.11 ـ

حتي روي يك PeNTium Pro 200 MHZ ـ براي يك سيستم بي درنگ بي فايده است ، چون يك درخواست مي تواند به طور پيوسته كنترل را در دست بگيرد و بقيه سيستم را مسدود كند . اولين نياز اين است كه سيستم عامل بايد چند نخي ( Multi – threaded ) و قابل پس گرفتگي باشد . براي بدست آوردن اين نيازها زمانبند بايد بتواند هر thread را در سيستم قبضه كند و منبع را به آن thread بدهد كه بيشترين نياز را دارد .

سيستم عامل (‌و معماري سخت افزار ) همچنين بايد وقفه هاي چند سطحي را بپذيرد تا در سطح وقفه انحصاراً اختيارداشته باشد .
نياز دوم : مفهوم اولويت نخ ( thread ) بايد وجود داشته باشد . مشكل پيدا كردن نخي است كه بيشترين نياز به يك منبع را دارد . در يك شرايط مطلوب ، يك RTOS منابع را به نخ يا درايوري مي دهد كه نزديك ترين ضرب الاجل را دارد . براي اين منظور ، اگرچه ، سيستم عامل بايد بداند چه وقتي يك نخ بايد كارش را تمام كند و چگونه هر نخ اين زمان را لازم دارد .

ولي هيچ RTOS به اين صورت وجود ندارد ، چون انجام دادن اين كار خيلي سخت است . بنابر اين توسعه دهندگان سيستم عامل نقطه نظر ديگري را گرفتند : آنها مفهوم سطوح اولويت براي نخها را مطرح كردند . طراح ، مسئول تبديل نيازهاي ضرب الاجل به اولويتهاي نخهاست . با اين فعاليت انساني ، مستعد خطا مي شود و يك سيستم بي درنگ مي تواند براحتي منحرف شود . طراح مي تواند در اين فرآيند دگرگوني به وسيله مثلاً استفاده از تئوريهاي زمانبندي سرعت يكنواخت و بعضي از نرم افزارهاي شبيه سازي ، كمك كند و اما اين مي تواند اصلا مفيد نباشد .
چون امروزه هيچ راه حل ديگري نيست ، نظريه اولويت نخ بايد وجود داشته باشد .
نياز سوم : سيستم عامل بايد از مكانيزمهاي همزماني نخهاي قابل پيش گويي ، پشتيباني كند . چون كه نخها ، داده ها را به اشتراك مي گذارند ( منابع ) و نياز به ارتباط دارند ‌، اين منطقي است كه مكانيزمهايي وجود داشته باشد ، به طور اين كه قفل شدني باشند و ارتباط در بين نخها داشته باشند .
نياز چهارم : يك سيستم ارث بري اولويت بايد وجود داشته باشد . در حقيقت اين مكانيزمها همزمان هستند و حقيقت اين است كه نخهاي متفاوت در يك فضاي حافظه اجرا مي شوند كه باعث تفاوت بين نخها و پردازشها مي شود . پردازشها فضاي حافظه يكساني را به اشتراك نمي گذارند .

بعنوان مثال : نسخه هاي قديمي UNIX به صورت Multi – thread نيستند و سيستم عامل چند كاره هستند . ولي task ها پردازشهايي هستند كه مي توانند فقط از طريق خطوط لوله و به اشتراك گذاشتن حافظه ، ارتباط برقرار كنند . هر دوي اين مكانيزمها از ويژگيهاي فايل سيستم بوسيله يك رفتار غير قابل پيشگويي استفاده مي كنند .

تركيب اولويت نخ ها و اشتراك منبع ها ،‌آنها را به نقطه ديگري سوق مي دهد : مشكل كلاسيك اولويت معكوس . قبل از انجام يك وضعيت اولويت معكوس ، حداقل سه تار نخ بايد درگير شوند . وقتي يك نخ با كمترين اولويت يك منبع را قفل كرد ( اشتراك با بالاترين ) تا زمانيكه نخ با اولويت متوسط باشد ، اجرا مي شود تا منبع قفل شده ، آزاد شود و نخ با اولويت متوسط اجرايش تمام شود . زماني كه يك نخ با اولويت بالا براي كامل شدن لازم دارد وابسته است به يك سطح اولويت پايين تر « معكوس اولويت » .

واضح است كه در اين چنين وضعيتي رسيدن به ضرب العجل سخت است .
به شكل ۱ توجه كنيد .
براي اجتناب از آن ، يك RTOS بايد اجازه ارث بري از اولويت را بر طبق پيشرفت نخ با كمترين اولويت بيشتر از نخ متوسط و بيشتر تا حد درخواست شده .
ارث بري اولويت به اين معني است كه نخ جانشين شده اولويت نخ مسدود را بلوكه كند ( البته اين تنها مورد در صورتي است كه نخ بلوكه شده يك اولويت بالاتر داشته باشد .)

بيشتر مردم براي يك طرح درست كه از اين مشكل اجتناب كند ، بحث مي كنند . اين روش براي درخواستهاي پيچيده درست نيست . تنها راه حل آن افزايش اولويت نخ به صورت دستي و قبل از اين كه يك منبع بلوكه شود ، است .
و اين دلالت دارد بر اين كه فقط دو نخ با اولويت متفاوت ، منبع نگه داشته شده را تقسيم مي كنند وگرنه هيچ راهي وجود ندارد .
آنچه كه از رفتار OS‌ بايد دانست :

بايد به نيازهاي تنظيم وقت رسيدگي شود . در حقيقت ، توسعه دهنده بايد تمام فراخواني هاي سيستم تنظيم وقت را بشناسد و همچنين رفتار سيستم را در همه شرايط بداند . بنابر اين مقادير زير بايد به طور صريح به وسيله سازنده RTOS معلوم شوند :
 تاخير وقفه ( زماني كه وقفه براي اجرا شدن لازم دارد ) :

كه اين تاخير بايد سازگار با نيازهاي كاربردي باشد و همچنين بايد قابل پيشگويي باشد. اين مقدار به تعداد وقفه هايي كه به طور همزمان رخ مي دهند وابسته است .
 هر فراخواني سيستمي ، بيشترين زمان را مي گيرد . اين بايد قابل پيشگوئي و مستقل از تعداد اشياء موجود در سيستم باشد .
 وقت گير ترين كار در OS ها و درايورها ، mask كردن وقفه هاست .

توسعه دهنده همچنين بايد نكات زير را بداند :
 سطوح وقفه سيستم .
 سطوح IRQ دستگاه ها ، بيشترين زماني كه مي گيرند و غيره .
وقتي كه همه معيارهاي قبلي شناخته شده ، مي توان يك سيستم بي درنگ سخت را روي اين OS تصور كرد .
البته نيازهاي اجرايي سيستم براي توسعه بايد با RTOS و سخت افزار انتخاب شده ، سازگار شود.