سلام دوستان
در کتاب استالینگ انتهای فصل ۵، مسئله ای با عنوان خوانندگان و نویسندگان مطرح شده است که برای ایجاد انحصار متقابل از دو روش راهنما و پیام استفاده کرده است. نویسندگان می خواهند بر روی ناحیه داده مشترک بنویسند و خوانندگان از ان ناحیه بخوانند. زمانی که نویسنده ای در حال نوشتن است هیچ خواننده ای نباید بخواند و هر لحظه فقط یک نویسنده می تواند بر روی این ناحیه بنویسد
در دو عکس ضمیمه شده راه حل این مسئله با استفاده از پیام به عنوان روش انحصار متقابل نشان داده شده اند. یکی از عکس ها الگوریتم این روش و عکس دیگر توضیح ان است. من اصلا توضیحش را متوجه نمی شوم. چگونه به ازای مقادیر مختلف متغیر count متوجه وضعیت خوانندگان و نویسندگان می شود. لطفا توضیح الگوریتم را شرح دهید
ممنون
مهمان عزیز شما قادر به مشاهده پیوندهای انجمن مانشت نمی‌باشید. جهت مشاهده پیوندها ثبت نام کنید.
مهمان عزیز شما قادر به مشاهده پیوندهای انجمن مانشت نمی‌باشید. جهت مشاهده پیوندها ثبت نام کنید.
(۲۵ اردیبهشت ۱۳۹۵ ۱۰:۱۲ ب.ظ)rad.bahar نوشته شده توسط: سلام دوستان
در کتاب استالینگ انتهای فصل ۵، مسئله ای با عنوان خوانندگان و نویسندگان مطرح شده است که برای ایجاد انحصار متقابل از دو روش راهنما و پیام استفاده کرده است. نویسندگان می خواهند بر روی ناحیه داده مشترک بنویسند و خوانندگان از ان ناحیه بخوانند. زمانی که نویسنده ای در حال نوشتن است هیچ خواننده ای نباید بخواند و هر لحظه فقط یک نویسنده می تواند بر روی این ناحیه بنویسد
در دو عکس ضمیمه شده راه حل این مسئله با استفاده از پیام به عنوان روش انحصار متقابل نشان داده شده اند. یکی از عکس ها الگوریتم این روش و عکس دیگر توضیح ان است. من اصلا توضیحش را متوجه نمی شوم. چگونه به ازای مقادیر مختلف متغیر count متوجه وضعیت خوانندگان و نویسندگان می شود. لطفا توضیح الگوریتم را شرح دهید
ممنون
مهمان عزیز شما قادر به مشاهده پیوندهای انجمن مانشت نمی‌باشید. جهت مشاهده پیوندها ثبت نام کنید.
مهمان عزیز شما قادر به مشاهده پیوندهای انجمن مانشت نمی‌باشید. جهت مشاهده پیوندها ثبت نام کنید.
سلام
(منظورم از اعداد ۱ تا ۶ خطوطی هست که در عکس ضمیمه شده مشخص کردم)
در ابتدای کار، متغیر count یک مقدار بزرگتر از تعداد کل خواننده‌ها به خودش اختصاص میده. این مقدار رو ظاهراً ۱۰۰ گرفته.
فرض کنیم اولین درخواستی که به مجموعه رسیده، درخواست نوشتن هست. count از ۰ بزرگتر هست اول کار، پس وارد ۱ میشه. ۲ برقرار نیست چون هیچ خواننده‌ای نبوده که عمل خواندن رو تموم کرده و دستور finished صادر کرده باشه. پس ۳ رو بررسی میکنه. صف عملیات نوشتن خالی نیست چرا که گفتیم درخواست نوشتن توسط یک نویسنده صادر شده، پس در صف مربوطه قرار گرفته (کنترلر به تمامی صف‌های نوشتن و خواندن و صف پیام‌های حاصل از اتمام اون‌ها دسترسی داره). پس در داخل ۳، دستور رو دریافت میکنه و ID نویسنده رو برابر با msg قرار میده (که توسط نویسنده فرستاده میشه). از مقدار count صد واحد کم میکنه (پس count میشه ۰). چون ۳ برقرار شده بود، دیگه ۴ بررسی نمیشه. ولی ۵ بررسی میشه چون به صورت if ساده هست نه else if. در ۵ پیغام دسترسی به نویسنده‌ای که به درخواستش رسیدگی شده داده میشه و همونجا اونقدر صبر میکنیم تا finished رو از اون نویسنده دریافت کنیم. در نهایت دوباره count به ۱۰۰ برگردونده میشه. ضمناً ممکن هست بیش از یک نویسنده درخواست داده باشند که تا وقتی که صف درخواست‌های نویسنده خالی نشده، اولویت‌های نویسنده‌ها رو در ۲ بررسی میکنیم. یعنی نویسنده‌ها به خواننده‌ها اولویت دارند.
فرض کنیم نویسنده‌ها مدتی درخواست ندادند و یک یا چند خواننده درخواست دادند. مقدار count صد هست پس وارد ۱ میشیم و سپس شرط ۴ برقرار هست. مقدار count رو میکنه ۹۹ و به اون خواننده اوکی میده. هیچ کدوم از ۵ و ۶ برقرار نیست. دوباره وارد ۱ میشه. ۲ رو چک میکنه ببینه خواننده‌ای هست که کارش رو تموم کرده باشه و پیام اتمام فرستاده باشه یا خیر (فرض کنیم خیر). دوباره در ۴ خواننده‌ی بعدی رو بررسی میکنه و ... . وقتی وارد ۱ شد و سپس ۲ رو بررسی کرد و دید خواننده‌ای کارش رو تموم کرده، پیام finish رو ازش میگیره و count رو یک واحد زیاده میکنه. گرفتن پیام finish به این معنی هست که اون خواننده رو از صفِ خواننده‌های فعال حذف میکنه.
اگر وسط این خواندن‌ها، یعنی تا وقتی که خواننده‌ای فعال هست، پیام نوشتن بیاد چی میشه؟ فرض کنیم ۳ تا خواننده‌ی فعال داریم و مقدار count شده ۹۷/ وارد ۱ میشه و بلافاصله ۲ رو بررسی میکنه، اگه خواننده‌ای کارش تموم و finish رد کرده باشه که بررسی میکنه و ...، اگه نه، ۳ رو چک میکنه میبینه صف خالی نیست. پیام نوشتنش رو دریافت میکنه و ID نویسنده رو به اونی که پیام رو داده set میکنه و از count صد تا کم میکنه. پس count میشه منفی سه. در پایین شرط ۵ برقرار نیست ولی ۶ هست! در داخل ۶ اونقدر صبر میکنه تا همه‌ی خواننده‌ها پیغام finish صادر کنند و هر بار که دریافت کرد یکی زیاد میکنه count رو. یعنی وقتی نویسنده‌ای منتظر هست ولی خواننده‌ها فعال هستند و حافظه‌ی مشترک رو ول نکردند، دیگه به خواننده‌ی جدید اجازه نمیده و اونقدر در ۶ صبر میکنه تا خواننده‌ها کارشون تموم بشه. پس مشکل انتظار بی‌نهایت برای نویسنده پیش نمیاد. ضمناً در بالای دیدیم که وقتی هیچی فعال نداشته باشیم ولی هم نوشتن بیاد هم خواندن، اولویت با نویسنده هست چون ۳ رو قبل از ۴ چک میکنه.
خلاصه توو ۶، هر ۳ تا خواننده رو صبر میکنه که آزاد بشن، بعد count میشه ۰ (از منفی ۳). پس ۶ تموم میشه و این بار شرط ۱ دیگه برقرار نیست ولی شرط ۵ برقرار هست. داخل ۵ به اون نویسنده اوکی میده و صبر میکنه کارش تموم بشه بعدش دوباره count رو به ۱۰۰ برمیگردونه.
پس وقتی count از ۰ بزرگتر هست هیچ نویسنده‌ای منتظر نیست چون دیدیم که وقتی نویسنده منتظر میشه، ۱۰۰ تا از count کم میکنه و در بهترین حالت count میشه ۰ (وقتی که هیچ خواننده‌ای فعال نباشه).
وقتی count برابر با ۰ هست، یعنی تمام خواننده‌های فعال رو سرویس دادیم و هیچ خواننده‌ای فعال نیست و وقتش هست که به تنها درخواست منتظر، یعنی درخواست نوشتن اجازه بدیم. توجه شود که چون تعداد خواننده‌ها از ۱۰۰ کمتر هستند، کم کردن‌های یک واحد یک واحد از count اون رو ۰ نمیکنه. وقتی ۰ شده یعنی کار درخواست نوشتن بوده!
وقتی count از ۰ کمتر هست، یعنی خواننده‌های فعال داشتیم که وسطشون درخواست نوشتن هم اومده که باعث شده علاوه بر اون مقداری که به سبب خواننده‌ها از count کم شده، ۱۰۰ تا هم این کم کنه و منفی بشه کلا. پس یعنی هم خواننده‌ی فعال داریم، هم درخواست نوشتنِ در صف انتظار.
![[تصویر: 404713_aj1s09l2cn5q15ojdzl5.jpg]](https://img.manesht.ir/404713_aj1s09l2cn5q15ojdzl5.jpg)
[attachment=19966]