Inter Process Communication (IPC)
AdolfMacro ( SPAM GEEK )نواحی بحرانی در IPC ( قسمت ۲ ) :
برای پرهیز از شرایط رقابتی در نواحی بحرانی نیز راهحل وجود دارد و آنها را شرایطی مینامیم که در آن mutul exclusion برقرار است .
به طور کلی مفومی که پشت mutul exclusion هست ، مانع انجام همزمان کار ها در نواحی بحرانی است .
گاهی یک فرایند که به فایل ها یا حافظه اشتراکی دسترسی دارد و یا مشغول انجام کارهای بحرانی است میتواند موجب ایجاد شرایط رقابتی بشود .
همیشه دسترسی های مشترک نیستند که موجب ایجاد شرایط رقابتی میشوند ؛ بلکه بهتر است بگوییم که بعضی از بخش های برنامه با عوامل مشترک بگونهای کار میکنند که رقابتزا است و این بخش ها را ناحیه بحرانی مینامیم .
دقت شود که در تمامی نواحی بحرانی دسترسی به حافظه مشترک جزوی از شروط اصلی ایجاد این مشکل است ، اما این بدان معنی نیست که هر دسترسی اشتراکی نیز موجب ایجاد شرایط رقابتی میشود.
در واقع برای رفع این مشکل به برقراری mutul exclusion نیاز است ؛ در نظر داشتن و سعی برای بقراری این مفهوم از شرایط رقابتی جلوگیری میکند اما زمانی که چند فرآیند موازی داریم که با استفاده از داده های اشتراکی به صورت صحیح و با کارایی بالا با یکدیگر همکاری میکنند برای داشتن راهحلی مناسب شروطی مهم وجود دارند و باید در نظر گرفته شوند که به شرح زیر است:
1 ) هیچ دو فرایندی نباید به طور همزمان وارد نواحی بحرانی همدیگر شوند .
2 ) هیچ فرضی مبنی بر نوع پردازنده یا سرعت نباید در نظر گرفته شود.
3 ) هیچ فرایندی نباید بیرون از محدوده بحرانی خود توانایی بلوکه کردن سایر فرایند ها را داشته باشد ( مثلا روش تناوبی که فرایند را یکی در میان جهت ورود به نواحی بحرانی بلوکه میکند )
4 ) هیچ فرایندی نباید در چرخهای پایان ناپذیر مبنی بر صبر کردن جهت خروج فرایند دو از ناحیه بحرانی قرار بگیرد .
در ادامه مثال هایی از انواع این راهحل ها جهت درک بیشتر موارد ذکر شده مطرح میشود و هر کدام از این مثال ها یکی از موارد بالا را روشنسازی میکند ...
راهحل busy waiting :
راحت ترین راهحل این مشکل این است که هنگام ورود هر فرایند به ناحیه بحرانی تمامی Interrupt ها نادیده گرفته شوند و بعد از خروج از این ناحیه همه آنها مجدداً فعال شوند ؛ با جلوگیری از Interrupt ها وقفه های دیگر نمیتوانند از فرآیندی به فرایند دیگر سوییچ کنند و این عمل کار عاقلانه ای نیست .
بر فرض که یک فرایند باعث شود که تمامی Interrupt های یک فضای آدرس در نظر گرفته نشوند و به هر دلیلی که احتمال بالایی نیز دارد دیگر نتواند موجب شود دوباره Interrupt ها در فضای آدرس در نظر گرفته شوند ( تاکید دوباره میکنم : هر دلیلی ممکن است داشته باشد ... ) این قضیه موجب میشود که سیستم به طور کلی دچار اختلال بشود و crash کند ؛
در پردازنده های چند هستهای معمولا این عمل موجب از کار افتادن یکی از هسته های پردازنده میشود و سایر هسته ها به درستی کار میکنند اما نهایتاً باز هم شرایط مشابه میتواند موجب ایجاد اختلال در آنها نیز بشود .
از طرفی دیگر در پردازنده های چند هستهای گاهی اوقات برای خود هسته نیز مفید است که Interrupt به جهت ایجاد تعداد محدودی از دستورالعمل هایش و جهت بروزرسانی متغیر ها و لیست های ورودی خود بکار بگیرد و از آن جهت کار های متفرقه و یا جلوگیری از شرایط رقابتی استفاده کند.
راهحل lock variables :
یک متغیر مشترک با مقدار اولیه صفر را در نظر بگیرید ؛ هنگام ورود به ناحیه بحرانی این متغیر را تحت شرایط true یا false بودن چک میکند و اگر صفر باشد ( در اینجا صفر یا همان false به معنای خالی بودن ناحیه بحرانی و اجازه ورود فرایند است ) متغیر را به مقدار 1 تغییر میدهد و وارد ناحیه بحرانی میشود و در غیر این صورت اگر 1 باشد صبر میکند تا متغیر به 0 تغییر کند .
دقیقا همان مثال قبلی printer spooler در این مورد نیز صدق میکند ، برای مثال هنگامی که فرایند a متغییر را صفر میبیند ممکن است وقتی که میخواهد آنرا به یک تغییر دهد و وارد ناحیه بحرانی شود ، دچار وقفه شده و پروسه b نیز متغیری که فعلا مقدار آن 0 است را بخواند و درحالی که هنوز مقدار متغیر global توسط فرایند a به 1 تغییر نکرده به ادامه کار بپردازد و در آنواحد فرایند a از حالت busy waiting خارج شود و او نیز وارد ناحیه بحرانی شود...
نهایتا همانطور که قبلا دیدیم استفاده از متغیرهای global و local ایده مناسبی نیست و باز با شکست مواجه میشود ؛ حتی اگر چندین بار تست کنیم که آیا صفر است یا خیر نهایتا ممکن است دوباره وقفه ها موجب ایجاد این شرایط شوند و mutul exclusion برقرار نشود ...
PART 2
Telegram : @SpamGeeks