صفحه محصول - پاورپوینت سیستم عامل

پاورپوینت سیستم عامل (pptx) 29 اسلاید

دسته بندی : پاورپوینت

نوع فایل : PowerPoint (.pptx) ( قابل ویرایش و آماده پرینت )

تعداد اسلاید: 29 اسلاید

قسمتی از متن PowerPoint (.pptx) :

Shahriar Pirnia http://www.pirnia.net Operating systemسيستم عامل Interprocess Communication 1- چگونه یک Process می تواند اطلاعاتی را به Process دیگر انتقال دهد ؟ 2- چگونه مطمئن شويم دو يا چند پروسس مزاحم همديگر نميشوند. مثلا هر دو نمی خواهند در يک فضای حافظه بنويسند. 3- وقتی پردازشها وابستگيهايی نسبت به هم دارند، دنباله صحيح پروسسها چگونه است. اغلب نیاز است که يک پردازش با پردازشهای دیگر بتواند ارتباط داشته باشد . به عنوان مثال Shell Pipeline یا پوسته سیستم عامل بصورت پردازشهای متوالی پیاده سازی شده است . خروجی Process اول باید به Process دوم داده شود و . . . . بنابراین نیاز است که پردازشها بتوانند با یک روش دارای ساختار مناسب با هم Communicate داشته باشند . حالا می خواهیم به برخی موضوعات مربوط به این ارتباط میان پردازشی Interprocess Communication (IPC) بپردازیم . چند موضوع باید بحث شود : شرايط مسابقه Race Conditions . . . next_free_slot = in sd[next_free_slot]=filename i in = next_free_slot +1 . . . Process i علت رخ دادن اشکال در مثال بالا این است که پروسس B استفاده از یکی از متغیرهای مشترک را زمانی شروع می کند که پروسس A هنوز کارش را با آن متغیر مشترک تمام نکرده است . انتخاب Primitive (عمل اولیه) مناسب برای دستیابی به Mutual Exclusion یک موضوع مهم طراحی در هر سیستم عاملی است و موضوعی است که بطور دقیق با جزئیات به آن می پردازیم . مسئله اجتناب از شرایط مسابقه بطور انتزاعی می تواند مطرح شود . برخی زمانها Process مشغول Computing (محاسبات) داخلی خودش و کارهای دیگری است که به شرایط مسابقه منجر نمی شود . برخی زمانهایک پردازش ممکن است در حال دستیابی به فایل يا حافظه مشترک یا کارهای بحرانی دیگری باشد که منجر به شرایط مسابقه می شود . تعریف : بخشی از برنامه که طی آن Shared Memory (حافظه مشترک) مورد دستیابی قرار می گیرد Critical region (ناحیه بحرانی) یا Critical Section (بخش بحرانی) نامیده می شود . اگر بتوانيم کاری کنيم که هيچ دو پردازشي همزمان در بخشهای بحرانی خود نباشند میتوانيم از شرايط مسابقه جلوگيری کنيم . Process ----------- . . . . . دسترسی به حافظه مشترک . . . . . ناحيه بحرانی برای اينکه پردازشهای موازی بطور صحيح و با کارآ يی بالا از داده مشترک استفاده کنند برآوردن چهار شرط زير ضروری است 1- هيچ دو پردازشی همزمان در بخش بحرانی نباشند. 2 - هيچ فرضی درباره سرعت و تعداد CPU ها در نظر گرفته نشود. 3- هيچ پردازشی هنگامی که خارج از ناحيه بحرانی اش است نبايد بقيه پردازشها را Block کند. هيچ پردازشی نبايد برای هميشه منتظر ورود به بخش بحرانی اش باقی بماند. 4- انحصار متقابل توسط در حال انتظار، مشغول است Mutual Exclusion with Busy Waiting در این بخش روشهای پیشنهادی برای دستیابی به انحصار متقابل ((mutual exclusion به گونه ای که وقتی یک Process مشغول Update حافظه مشترک است ، هیچ Process دیگری به ناحیه بحرانی اش وارد نشود را بررسی می کنیم . (Disabling interrupts) غير فعال نمودن وقفه ها (Lock Variables) استفاده از متغيرهای قفل (Strict Alternation) تناوب قطعی (Peterson’s Solution) راه حل پترسون دستورالعمل TSL (Test and Set Lock) (Disabling interrupts) غير فعال نمودن وقفه ها ساده ترین راه این است که هر Process درست پس از اینکه وارد ناحیه بحرانی اش شد ، تمام Interrupt ها را غیر فعال (disable) کند و درست قبل از ترک ناحیه بحرانی اش ، آنها را دوباره فعال بکند . وقتی Interrupt ها غیر فعال شوند . هیچ Clock Interrupt ای رخ نمی دهد . CPU هم که فقط در نتیجه وقفه ( وقفه Clock و بقیه وقفه ها ) از یک Process به Process دیگر Switch می نمود ، پس با Disable شدن وقفه ها ، CPU به Process دیگر Switch نمی کند . پس وقتی یک Process ، وقفه ها را Disable کند با خیال راحت بدون اینکه Process دیگری مزاحمش شود می تواند حافظه مشترک را Update کند . اما این رویکرد بطور کلی جالب نیست زیرا عاقلانه نیست به یک User Process قدرت خاموش کردن Interrupt ها را بدهیم . فرض کنید یک Process وقفه ها را غیر فعال بکند و دیگر هیچوقت آنها را فعال نکند . این پایان سیستم است . به علاوه اگر سیستم Multiprocessor (دارای چند ریزپردازنده) باشد ، غیر فعال نمودن وقفه ها فقط بر روی CPU ای که دستورالعمل Disable را اجرا کرده است موثر است و بقیه Processor ها می توانند Process های دیگری را اجرا کنند که به حافظه مشترک دسترسی داشته باشند . از طرف دیگر اغلب برای ((Kernel هسته سیستم عامل مناسب است که در مورد تعداد کمی از دستورالعملها که مربوط به Update نمودن متغیرها و لیستها است ، وقفه ها را غیر فعال کند . مثلا وقتی لیست Process های آماده اجرا در حال Update است و در یک حالت Inconsistent( ناسازگار) است ، اگر وقفه ای رخ دهد ممکن است منجر به Race Condition شود . جمع بندی : غیر فعال نمودن وقفه ها توسط خود سیستم عامل اغلب یک تکنیک سودمند است ولی به عنوان یک مکانیزم کلی Mutual Exclusion برای User Process ها مناسب نیست .