Windowse NT

Windowse NT as Real – time OS ?

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

آيا Windowse NT  مي تواند اين نيازها را برآورده سازد ؟

Windowse NT as Real – time OS ?

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

آيا Windowse NT  مي تواند اين نيازها را برآورده سازد ؟

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

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

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

مقدمه

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

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

آيا اين عناصر اجازه مي دهند كه Windowse NT  بعنوان يك RTOS   طبقه بندي شود ؟

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

تعريف :

يك سيستم بي درنگ به ورودي هاي محرك غير قابل پيش بيني با يك روش بهنگام قابل پيش بيني پاسخ مي دهد .

براي انجام آن بعضي نيازهاي اصلي لازم مي شود :

1 ـ يافتن ضرب العجل . بعد از رخ دادن رويداد يك اقدام در يك زمان محدود و از قبل تعيين شده بايد انجام شود و از بين رفتن زمان ضرب الاجل باعث خطاي نرم افزاري مي شود .

واكنش در مقابل اين فقدان بعنوان يك مشكل اجرايي مطرح مي شود كه مي تواند به وسيله يك پردازنده سريع حل شود . اما اثبات مي شود كه استفاده از يك پردازنده سريع لزوماً مشكل ضرب الاجل را حل نمي كند .

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

كه به وسيله استفاده بيشتر از يك پردازنده سيستم بدست مي آيد . سيستم هاي بي درنگ سخت و نرم :

مي توان سيستمها ي  بي درنگ را از يك نظر به دو دسته سخت و نرم تقسيم بندي كرد .

 خصوصيات سيستمهاي بي درنگ سخت عبارتند از :

×                     تحت هيچ شرايطي تاخير پذيرفته نيست .

×                    اگر تاخير پيش آيد ، نتايج بي فايده اند .

×                     هزينه گذشتن از ضرب الاجل بي اندازه زياد است .

يك مثال خوب براي سيستم بي درنگ سخت سيستم كنترل چرخهاي  هواپيماست .

 خصوصيات يك سيستم بي درنگ نرم عبارتند از :

×                    نتايج تاخير ارزش بيشتري دارند .

×                     كارآيي پايين تر پذيرش براي تاخير .

بعنوان مثال ماشين 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 ها پردازشهايي هستند كه مي توانند فقط از طريق خطوط لوله و به اشتراك گذاشتن حافظه ، ارتباط برقرار كنند . هر دوي اين مكانيزمها از ويژگيهاي فايل سيستم بوسيله يك رفتار غير قابل پيشگويي استفاده مي كنند .

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

واضح است كه در اين چنين وضعيتي رسيدن به ضرب العجل  سخت است .

به شكل 1 توجه كنيد .

براي اجتناب از آن ، يك RTOS بايد اجازه ارث بري از اولويت را بر طبق پيشرفت نخ با كمترين اولويت بيشتر از نخ متوسط و بيشتر تا حد درخواست شده .

ارث بري اولويت به اين معني است كه نخ جانشين شده اولويت نخ مسدود را بلوكه كند  ( البته اين تنها مورد در صورتي است كه نخ بلوكه شده يك اولويت بالاتر داشته باشد .)

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

و اين دلالت دارد بر اين كه فقط دو نخ با اولويت متفاوت ، منبع نگه داشته شده را تقسيم مي كنند  وگرنه هيچ راهي وجود ندارد .

آنچه كه از رفتار OS‌ بايد دانست :

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

×                     تاخير وقفه ( زماني كه وقفه  براي اجرا شدن لازم دارد ) :

كه اين تاخير بايد سازگار با نيازهاي كاربردي باشد و همچنين بايد  قابل پيشگويي باشد. اين مقدار به تعداد وقفه هايي كه به طور همزمان رخ مي دهند وابسته است .

×                     هر فراخواني سيستمي ، بيشترين زمان را مي گيرد . اين بايد قابل پيشگوئي و مستقل از تعداد اشياء موجود در سيستم باشد .

×                     وقت گير ترين كار در OS ها و درايورها ، mask كردن وقفه هاست .

توسعه دهنده همچنين بايد نكات زير را بداند :

×                     سطوح وقفه سيستم .

×                     سطوح IRQ دستگاه ها ، بيشترين زماني كه مي گيرند و غيره .

وقتي كه همه معيارهاي قبلي شناخته شده ، مي توان يك  سيستم بي درنگ سخت را روي اين OS تصور كرد .

البته نيازهاي اجرايي سيستم براي توسعه بايد با  RTOS   و سخت افزار انتخاب شده ، سازگار شود.

آيا Windows NT اين نيازها را برآورده مي سازد ؟

آيا Windows NT   قابل پس گرفتگي و Multi – thread  است ؟

  واضح است كه Windows NT بخاطر قابل پس گرفتني بودن وويژگي Multi – thread كه دارد ، نياز اول يك سيستم بي درنگ را برآورده مي سازد . بايد قابليت پس گرفتني Windows NT را بررسي كنيم . بنابر اين ما بايد ساختار Windows NT را براي سنجيدن اين كه چطور و چگونه جنبه هاي بي درنگ يك سيستم مي تواند در Windows NT بكار برده شود ، فراخواني كنيم .

اولويتهاي نخ  (  نياز دوم ) :

در يك سيستم بي درنگ همه كارها هم اولويت نيستند . بعضي از آنها ( آنهائي كه زمان بحراني دارند ) اولويت بالاتري دارند . بقيه مانند نمايش دادن وضعيتي  از سيستم ، ثبت كردن واقع درون فايل .

بنابر اين OS بايد بتواند اولويتهاي مختلفي را به كارها بدهد .

در Windows NT مفهوم اولويت كاملاً پيچيده است :

دو كلاس براي اولويت پردازشها وجود دارد : كلاس بي درنگ و كلاس   ديناميك .

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

اولين كلاس مي تواند در يك سيستم بي درنگ براي ضمانت  قابليت پيشگويي سيستم بكار رود . بايد توجه شود كه براي يك كار غير بي درنگ در يك سيستم بي درنگ ، كلاس  دوم هميشه مي تواند استفاده شود .

يك پردازش يك سطح اولويت  پايه دارد كه فقط مي تواند توسط درخواست خودش عوض شود .

يك نخ در پردازش يك اولويت در بازه 2    سطح اولويت پايه پردازش  بعلاوه تعداد زياد سطوح كلاس مي تواند داشته باشد . بعنوان مثال نخهاي يك پردازش با اولويت پايه 24 ( كلاس بي درنگ ) مي تواند هر اولويتي را بين 26 , 22  بعلاوه سطوح 31 , 16  داشته باشد .

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

بيشتر RTOS هاي پيشرفته حداقل  256  اولويت را مي پذيرند .

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

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

اولويت معكوس :

همانطور كه قبلاً اشاره شد مشكل اولويت معكوس در يك سيستم بي درنگ يك نوع كلاسيك است . بنابر اين  در يك RTOS  سيستم همزمان سازي Mutexe ها ، سمافورها و نواحي بحراني را فراخواني مي كند كه بايد توانايي ارث بري اولويت را اداره كند . در  Windows NT  اين توانايي  غير ممكن است . بنابر اين نياز چهارم برآورده نمي شود . مشكل ديگري كه وابسته است به اولويت معكوس در  Windows NT   بخاطر اجراي بعضي از فراخواني هاي GUI  سيستم است . آنها به طرز همزمان ( نخ فراخوانده شده ، معلق مي شود تا ا تمام فراخواني سيستم ) توسط يك پردازش جاري در يك كلاس اولويت غير بي درنگ استفاده مي شوند . پس از آن يك نخ در كلاس    بي درنگ پايين تر مي تواند از اجراي نخي ديگر با اولويت بالاتر جلوگيري كند .

به طور نسبي تعداد كمي از اولويتها وابسته به مشكل اولويت معكوس هستند ، باعث مي شوند كه  Windows NT  فقط براي سيستمهاي بي درنگ ساده مناسب شود ( تعداد   وقايع متنوع كم باشد ) .

   خصوصيات Win 32   API  

چرا ويندوز NT انتخاب شد ؟ همانطور كه قبلاً ذكر شد ، ويندوز NT   براي داشتن سيستم  عامل مشترك درسطوح مختلف در سلسله مراتب صنعتي كمپاني ، جالب توجه است . اما نقطع جالب توجه ديگر براي بررسي غني و قدرتمند  بودن Win 32   API است .

كه داراي مقدار زيادي Platform هاي توسعه يافته ، كامپايلرهاي خوب و همچنين مهندسهايي كه API  را به خوبي مي دانند ، مي باشد. مشخصه هاي API بسيار زياد مي باشد . اين خيلي مهم است كه شما نياز به ساخت يك درخواست Multi – thread  چند  نخ قدرتمند داشته باشيد . تنها سوال براي فهميدن اين است كه آيا شما قادر به ساخت درخواست بي درنگ قابل اعتماد بر روي آن هستيد . براي انجام آن ، فراخوان سيستم بايد قابل پيشگيري باشد و مستقل از تعداد شي ها در سيستم باشد .

براي اندازه گيري اين ها چندين تست ساده انجام داده ايم . يا پردازشي تعريف كرديم ( متعلق به كلاس بي درنگ ) كه داراي يك نخ اجرايي همزمان فراخواني سيستم است .

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

ما مطمئن هستيم كه هيچ جايگزيني  در طول انجام تست اتفاق نمي افتد و همچنين هيچ منبعي قفل نشده است و نيز اندازه هاي ما با اهميت مي باشد .

ما همچنين تاخير معرفي شده بوسيله رديابي فعاليت و حذف آن از نتايج تست را اندازه گيري كرده ايم . تست انجام شده بر روي پنتيوم 100 MHZ  با     204 MB , RAM  بود .براي درخواست Mutex  فراخوان سيستم ، به طور مثال : ما به طور متوسط 35 MS دريافت مي كنيم . اما ماگزيمم يك بار بالاي 68o ms بود .

به شكل 3 توجه شود .

چرا ؟ اين مساله به سادگي وابسته به وقفه است چه از ديسك باشد يا از شبكه به طوري كه اين تنها فعاليت ممكن ازسيستم است ( اين ماشين به شبكه متصل شده است ) . اين زمان زيادي دوباره توليد مي كند هنگامي كه سيستم به طور مصنوعي با ديسك بار شود و شبكه در زمان انجام تست انتقال مي يابد .

بنابر اين تاخير فراخوانهاي سيستم را به بالاي چند ميلي ثانيه متوقف مي كنيم .

همانطور كه گفته شد Win 32   API بسيار غني است . اما بايد توجه شود كه به خوبي براي بي درنگ طراحي نشده است . به طور مثال در خواستهاي  Mvtex به صورت FIFO و بدون اولويت وارد صف مي شوند . كه اين بزرگترين مانع براي قابل پيشگويي بودن آن است . توجه زيادي هنگام انتخاب يك فراخوان سيستم بايد بكار برده شود . به طور مثال ، براي همزماني نخ ها در يك پردزاش ، ناحيه بحراني بايد به هر فراخوان ترجيح داده شود .  ( اين فراخواني فقط يك ميليونيم ثانيه طول مي كشد كه با 35   ms  ، mutex  مقايسه شده است . اين فراخوان فقط در اين حالت خاص طراحي شده است ( نخ ها متعلق به يك پردازش هستند ) به طور نرمال تعويض متن بين دو نخ از يك پردازش خيلي سبك  تر از يكي بين دو پردازش است .

آخرين تبصره مربوط به API : هنگام استفاده از فراخوان سيستم APT بايد توجه داشت كه بعضي از آنها توسط اجراي پردازشهاي سيستمي با اولويتهاي كمتر و به صورت همزمان اجرا مي شوند . بنابر اين فراخواني نخ منتظر تكميل فراخواني خواهد ماند . اين مسائله مي تواند نتيجه شود در اولويتهاي معكوس .

نتيجه ما بعد از اين تست ساده اين است كه : علاوه بر قدرت API  ، هسته اصلي و مديريت I / O  به خوبي با  رويدادهاي بي درنگ در سطح درخواست مطابق نيست . ما بعداً بحث خواهيم كرد اگر اين شكل در سطح درايور حل   شود .

مديريت وقفه :

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

به شكل 4 توجه شود .

شكل 4 نشان مي دهد كه چگونه ويندوز NT براي ارتباط با سخت افزار طراحي شده است .

تنها راه براي رسيدن به سخت افزار از طريق درايور هسته مي باشد .

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

درايو مسئول اداره وقفه توليد شده توسط سخت افزار است . براي انجام اين ، يك مكانيزم اصلي براي افزيش واكنش سيستم عامل انتخاب شده است .

وقفه ها در دو مرحله اداره مي شوند . اول ، وقفه توسط يك روتين سرويس دهي به وقفه ( ISR )    كوچك اداره مي شود. بعد از آن كار توسط اجراي يك DPC   (Deferred Procodure Call  ) كامل مي شود . اين جريان رويدادهاي زير را مي رساند .

×                     رخدادهاي وقفه

×                    پردازشگر sp , pc را ذخيره كرده و فرستنده را فراخواني مي كند .

×                     سيستم عامل متن را ذخيره كرده و  ISR را فراخواني مي كند .

×                     درايور ISR  را در  كمترين زمان ممكن اداره مي كند ، فقط اعمال بحراني را انجام مي دهد ( خواندن و نوشتن ثباتهاي سخت افزار )

×                     درايو تابع DPC ( فراخواني تابع به تعويق افتاده ) را فراخواني مي كند   ( در حقيقت اين يك صف اداره شده توسط مدير I?O مي باشد .

×                     درايور ISR را خارج مي كند .

×                     سيستم عامل متن را باز مي گرداند .

×                     پردازشگر sp , pc  را باز مي گرداند .

×                    بعد از آن DPCV  قريب الوقوع در اولويت DISPATCH -  LEVEL  برنامه ريزي مي شود . اين يك نوع وقفه نرم افزاري است .

×                     بعد از  اتمام همه DPC هاي قريب الوقوع ، سيستم عامل در خواستهاي كاربر را دوباره برنامه ريزي مي كند .

به شكل 5 توجه شود .

همانطور كه معلوم است مديريت وقفه در ويندوز NT  بسيار پيچيده است . يك ISR بايد به صورت درست يعني كوتاهترين حالت ممكن طراحي شود .

بنابر اين اكثر درايورها كارهاي زيادي در DPC انجام مي دهند . ( آنهايي كه فقط توسط ISR  قابل پس گرفتن هستند ) باعث مي شوند كه DPC  هاي ديگر منتظر اتما مشان باشند . همانطور كه همه DPC بر روي يك سطح اولويت اجرا مي شود .

 درايور ويندوز NT به شما مي گويد كه : ISR  توسط ISR با اولويت بالاتر قابل پس گرفتن است و DPC داراي اولويت بالاتري نسبت به كاربر و  نخ هاي سيستم است . اما همانطور  كه همه DPC ها در يك سطح اجرا مي شوند و همانطور كه سياستي در هنگام طراحي درايور براي كاهش ISR به مقدار مينيمم خود بايد استفاده شود . ( به تعويق انداختن  باقيمانده كار بحراني در DPC ) ، DPC شما منتظر DPC هاي ديگر خواهد ماند تا اين كه كامل شود . در نتيجه درخواست شما بستگي به ديگر ماشينهاي درايور خواهد داشت .

آيا تفاوتي در RTOS  وجود دارد ؟  قطعاً وجود دارد .  در RTOS ، ابتدا توسعه دهنده بايد بداند كه در كدام سطح درايورهاي ديگر اجرا مي شوند . معمولا مقداري فضاي آزاد براي وقفه ها در بالاي درايورهاي استاندارد وجود دارد . تمام كارهاي بحراني بعد از آن در ISR  انجام مي شود و به توسعه دهنده اجازه خواهد داد كه وضعيت درايور را وابسته به زمان توقف درخواست تنظيم كند . در ويندوز ISR , NT   خيلي سريع مي باشد ، بنابر اين وقفه ها براي مدت زيادي بلوكه نمي شوند اما هيچ چيز در ISR اتفاق نمي افتد . اكثر كارها به DPC به تعويق مي افتند .

بنابر اين اگر شما از سومين دسته  ماشين درايور كه بد طراحي شده استفاده كنيد ، ضرب العجل را از دست خواهيد داد ، مگر اين كه شما از سياست مايكروسافت پيروي نكنيد و تمام كار را در ISR انجام دهيد ـ اما آن وقت ، چرا از سيستم عامل استفاده مي كنيد ؟

به شكل 6 توجه شود .

اما توجه شود كه اين مي تواند بسيار وخيم باشد . همان طور كه ما كشف كرديم كه بعضي از DPS  ها از هاردديسك و درايورهاي شبكه بيشتر از چند ميلي ثانيه طول مي كشند .

مديريت حافظه :

نكته ديگر كه در طراحي سيستم بي درنگ بايد در نظر گرفته شود سياست مديريت حافظه از RTOS  است .

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

بنابر اين ويندوز NT   به شما اجازه مي دهد كه صفحه ها را در حافظه در طي فراخواني تابع قفل مصنوعي ، قفل كنيد .

Jeffrey Richter  مي گويد كه ويندوز  NT  هنوز مي تواند قفل صفحه را باز كند و آنها را به ديسك  بفرستد  اگر همه پردازش غير فعال باشد .

گرچه ما هيچ بررسي براي تشريح آن نكرده ايم ،‌ تنها چيزي كه ما در پيداكردن آن موفق شده ايم تخصيص حافظه است براي پنجره اي كه بتواند بيرون فرستاده شود   ( swap out )  وقتي كه آن را iconise  مي كنيد . بنابر اين به طور نرمان براي درخواستهاي بي درنگ ، اين يك مشكل نخواهد بود . آيا مورد قبلي هنوز يك مشكل است ؟ نيست اگر درخواست و درخواستهاي دسته سوم ديگر خوب طراحي شده باشد و بيشتر از فضاي فيزيكي حافظه طلب نكند .

موارد ديگر براي بررسي :

بعضي از نكات ديگر بايد زمان سعي براي استفاده از سيستم عامل براي درخواستهاي بي درنگ يا جايگزين بررسي شوند .

×                     براي درخواستهاي جايگزين ، جاگيري حافظه به طور كلي يك مساله كليدي است . ويندوز NT  داراي جاگيري حافظه بسيار در مقايسه با ديگر RTOS ها مي باشد .

×                     اكثر اوقات شما نيازي به صفحه كليد و يا نمايش نداريد .

×                     براي  سري  توليدات بزرگ ، مجوز ويندوز NT   بسيار گران مي باشد . 255 دلار براي ايستگاه كاري 4 ، NT ( شما مي توانيد بدست بياوريد 186 دلار براي NT 3 . 5  با بيش از 3000 واحد و حتي كمتر ، براي حجم زيادي ) .

نتيجه : آيا ويندوز NT   مي تواند به عنوان RTOS  استفاده شود ؟

ما در اين مقاله نمايش مي دهيم كه ، همانطور كه طراحي شده است براي كار اصلي با درخواستهاي شناخته شده ، محيط خروجي براي حمايت درخواستهاي بي درنگ نمي باشد .

×                     تعداد اولويتهاي قابل دسترس در كلاس بي درنگ براي درخواستهاي بي درنگ بسيار پايين است .

×                    مشكل اولويتهاي معكوس در سيستم عامل حل نشد . ( براي پردازشهاي كلاس  بي درنگ ) .

×                     براي درخواستهاي جايگزين ، جاگيري حافظه بسيار زياد است و مجوز بسيار گران مي باشد .

×                     ماشينهاي درايور زمان زيادي را در DPC‌ مي گيرند و هيچ پيش دستي  با ديگر DPC  ها ممكن نيست .

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

×                     سيستم هاي بي درنگ نرم كه احتياجات آن اجازه مي دهد كه ضرب العجل ما گاهي اوقات از دست داده شوند .

×                     سيستم ساده جايي كه تعداد انواع مختلف از رويدادها زياد نباشد          ( قابليت پيشگيري DPC بالاتر است ) .

×                    بار CPU  هميشه پايين مي ماند ( سيستم DPC زمان براي اجرا دارد )

×                     تعداد كمي يا هيچ درايور دسته سومي يا حداقل يك انتخاب خوب درايورهاي دسته سوم . ( كه منبع نياز به چك دارند )

×                     كارهاي بحراني ( يا حتي همه كارها ) در سطح DPC انجام مي شوند يا به صورت بهتر در ISR .

اين مورد آخر ، كاربر سيستم عامل را بي معني مي كند ، اما براي سيستم  هاي بي درنگ سخت ، ويندوز NT  خارج از سوال است . سيستم شما هرگز قابليت پيشگويي كافي ندارد .

چه چيزي در ويندوز NT  بايد تغيير كند تا براي سيستم هاي بي درنگ سخت كار باشد ؟

پردازش كلاس بي درنگ بايد سطوح اولويت بيشتري داشته باشد . شكل اولويت معكوس بايد حل شود . تمام  سيستم وقفه بايد عوض شود :

×                     داشتن DPC  بهترين نظر است اما بايد سطوح اولويت زيادي داشته باشد .

×                    DPC بايد داراي حق تقدم باشد توسط DPC  هاي ديگر با اولويت  بالاتر .

×                     درايورهاي دسته سوم و درايورها بايد قابل پيكربندي باشند ( سطح اولويت ISR ، سطح  اولويت DPC ) .

×                     درايورهاي دسته سوم بايد براي توسعه دهنده ( كسي كه حداقل بايد مينيمم زماني را كه يك ماشين درايور مي تواند طول بكشد بداند .

( در طول ISR ، درطول DPC )

×                     زماني كه سيستم عامل توليد وقفه مي كند بايد براي توسعه دهنده شناخته شده باشد .

×                     زماني كه هر فراخواني سيستم طول مي كشد بايد بالاخره براي توسعه دهنده مشخص شود .

آيا مايكروسافت مايل است كه چنين بهبودي را در ويندوز NT  معرفي نمايد ؟