کاربردهای چندگانه پیغام های REPLY:

1. 1. یک پیغام REPLY به عنوان پیغام از پروسه‌ای که در حال درخواست دادن نیست عمل می‌کند.

1. 1. یک پیغام REPLY به عنوان یک پاسخ جامع از پروسه‌هایی که دارای درخواست‌های با اولویت بالاتر هستند عمل می‌کند.

یک پیغام REPLY(Rj) از سوی Pj نشان می‌دهد که Rj همان “REQUEST” ای است که Pj آخرین بار ارسال کرده و برای آن CS اجرا شده است. این نشان می‌دهد که همه “REQUEST” هایی که دارای اولیتی بیشتر یا مساوی اولیت Rj هستند CS را به پایان رسانده و دیگر در حال رقابت نیستند. وقتی یک پروسه Pi پیغام REPLY(Rj) را دریافت می‌کند، می‌تواند آن “REQUEST” هایی که اولویت‌شان بزرگتر یا مساوی اولویت Rj از صف محلی بوده‌اند را حذف کند. بدین ترتیب، یک پیغام REPLY یک پاسخ منطقی بوده و نشان‌دهنده یک پاسخ جامع از سوی همه پروسه‌هایی است که درخواست‌های با اولویت بالاتر ارسال کرده‌اند.

کاربردهای پیغام FLUSH:
یک پروسه یک پیغام FLUSH را پس از اجرای CS به پروسه‌ای که به صورت همزمان درخواست داده و دارای بالاترین اولویت بعدی است (در صورت وجود) ارسال می‌کند. در زمان ورود به CS، یک پروسه می‌تواند وضعیت همه پروسه‌های دیگر را در حالت‌های همسان ممکن با خود تعیین کند. تمامی پروسه‌های دیگر یا در حال درخواست دسترسی به CS هستند و اولویت درخواستشان شناخته شده است، یا در حال درخواست نمی‌باشند. در زمان اتمام اجرای CS، هر پروسه Pi موارد زیر را می‌داند:

1. 1. درخواست‌های فرایندهای دارای اولویت همزمانی پایین‌تر (کمتر از اولویت Pi) در صف محلی Pi در حال انتظار برای اجرای CS می‌باشند.

1. 1. پروسه‌هایی که REPLY را برای Ri به Pi فرستاده‌اند، هنوز در حال درخواست نبوده، و یا با اولویت کمتری به نسبت Pi درخواست می‌دهند.

1. 1. پروسه‌هایی که درخواست‌های خود را همزمان با Ri ارسال کرده‌اند، با اینکه اولویت بالاتری دارند یا درخواست ارسال نکرده و یا با اولویت کمتری درخواست خود را ارسال می‌دارند (به نسبت Pi).

“REQUEST” های دریافت شده از پروسه هایی که در ۲ و ۳ معرفی شدند با Ri همزمان نیستند، درخواستی که برایش Pi تازه اجرای CS را به پایان رسانده است. اینگونه “REQUEST” ها که قبل از اتمام CS توسط Pi دریافت می‌شوند به تعویق می افتند تا زمانی Pi که منطقه بحرانی خود را به اتمام برساند. سپس Pi یک پاسخ به هر کدام از این “REQUEST” های به تعویق افتاده به محض اتمام CS خود ارسال می‌دارد. بدین ترتیب، پس از اجرای CS، Pi یک پیغام FLUSH(Ri) به Pj ارسال می‌دارد که همان پروسه همزمان با بالاترین اولویت بعدی در حال ارسال درخواست است. برای هر پروسه Pk شناسایی شده در ۲ و ۳ که در حال درخواست است، “REQUEST” مربوطه تا زمانی که Pi منطقه بحرانی را ترک کند به تعویق می‌افتد، که در همین زمان Pi به Pk یک پاسخ ارسال می‌دارد. با این رفتار، Pi به هر دو Pj و Pk اجازه وارد شدن به CS را با توجه به Pi می‌دهد. Pj و Pk باید از یکدیگر اجازه گرفته، و هر کدام که اولویت بالاتری داشت اول وارد CS می‌شود.
کاربردهای چندگانه پیغام های REQUEST:
پروسه Pi که سعی در استفاده از انحصار متقابل دارد یک پیغام “REQUEST” به همه پروسه‌های دیگر ارسال می‌کند. هنگام دریافت یک پیغام “REQUEST"، پروسه Pj که در حال درخواست نیست بلافاصله یک پیغام REPLY ارسال می‌دارد. در صورتی که پروسه Pj در حال ارسال درخواست به صورت همزمان باشد، دیگر پیغام REPLY ارسال نمی‌دارد. در صورتی که درخواست Pj دارای اولویت بالاتری باشد، “REQUEST” دریافتی از Pi به عنوان پاسخی برای Pj عمل خواهد کرد. Pj سرانجام CS را قبل از Pi انجام خواهد داد و سپس از طریق زنجیره‌ای از پیغام‌های FLUSH/REPLY، سرانجام Pi یک یک پاسخ منطقی برای درخواست خود دریافت خواهد کرد.
در الگوریتم پیشنهاد شده در ]۶۵[، یک پیغام “REQUEST” دارای سه هدف به شرح زیر است. فرض کنید که هر دوی Pi و Pj در حال ارسال همزمان درخواست هستند. علاوه بر این، فرض کنید که “REQUEST” مربوط به Pi دارای اولویت بالاتری به نسبت “REQUEST” مربوط به Pj است.

1. 1. یک پیغام “REQUEST” به عنوان یک پیام درخواست عمل می‌کند.

1. 1. پیغام “REQUEST” از سوی Pi به Pj: این پیغام “REQUEST” به Pj به Pj نشان می‌دهد که Pi هم هنوز در رقابت باقی است و دارای اولویت بالاتری می‌باشد. در این مورد، Pj باید منتظر FLUSH/REPLY از سوی برخی پروسه‌ها باشد.

1. 1. پیغام “REQUEST” از سوی Pj به Pi: این پیغام “REQUEST” به Pi به عنوان پاسخی به Pi عمل می‌کند.

بدین ترتیب، وقتی “REQUEST” ها همزمان هستند هیچ پاسخی ارسال نخواهد شد.
پس از شکست هر پروسه در صف، یا سیستم متحمل بار شده و یا پس از دوره‌ای یک انتخاب رخ داده و سیستم جدیدی انتخاب می‌گردد. حالا الگوریتم پیشنهادی شروع به بازیابی در گام‌های ذیل می کند، تا اطلاعات از دست رفته من جمله صف‌ها و پرچم‌های مرتبط با CS بازیابی شوند. بدین ترتیب، سیستم مربوطه به موقعیت نرمال خود باز می‌گردد. گام‌های این الگوریتم از این قرارند:

1. 1. a) همه پروسه‌هایی که در سیستم به تازگی ایجاد شده قرار دارند، پیغامی ارسال می‌کنند که خود را معرفی کرده و همچنین بدین معنی است که یک مبدا جدید وجود دارد.

1. 1. b) همه کلاینت‌ها پس از دریافت پیغام مبدا جدید (NEWEPOCH) متوجه می‌شوند که یک سیستم جدید در سیستم توزیع شده وجود داشته و هر کدام از آنها بسته به موقعیتش می‌توانند پاسخ‌های زیر را ارسال کنند:

1. 1. کلاینت‌هایی که نه در CS قرار داشته و نه درخواستی برایش دارند، پیغام نداشتن درخواست را ارسال می‌کنند (می‌توان در شرایط بهبود یافته این پیغام را حذف کرد). و پروسه‌ها کاری برای این نوع پیغام‌ها انجام نمی‌دهند.

1. 1. کلاینت‌هایی که در CS قرار دارند یک پیغام “IN-REGION” (درون ناحیه) شامل تعدادی از کلاینت‌ها و نام CS ارسال می‌دارند.

1. 1. کلاینت‌هایی که در CS قرار ندارند اما می‌خواهند وارد شوند و پیغام “OK” را دریافت نکرده‌اند باید درخواست دیگری به سایر پروسه‌ها ارسال کنند. این پیغام شامل تعداد کلاینت‌ها، نام CS که می‌خواهند وارد آن شوند و برچسب زمانی که به اولین درخواست مرتبط است می‌شود. همه پروسه‌های مرتبط دیگر پس از دریافت پیغام خود را بر اساس برچسب زمانی‌شان تغییر داده و آنها را وارد صفی می‌کنند که مرتبط به آن CS است. بدین ترتیب، پس از دریافت پیغام‌های درخواست از همه کلاینت‌ها، صف‌های سیستم پیشین در سیستم جدید شکل می‌گیرند. باید بگوییم که حفظ برچسب‌های زمانی پروسه‌ها ضروری است.

1. 1. c) سیستم توزیع شده چک می‌کند که ببیند آیا هیچ پرچم تنظیم مجددی با صف لغو شده در سیستم وجود دارد یا نه. نباید هیچ وجود داشته باشد. اگر یکی هست، پیغام “OK” به پروسه در ابتدای صف ارسال می‌شود. بدین ترتیب سیستم جدید می‌تواند به جای سیستم قدیمی به کار خود ادامه دهد.

شکل ‏۳‑۲- چارت زمان بندی برای ۳ پروسه وقتی P1 می میرد ]۶۵[
شکل ۳-۲ نشان می‌دهد که به پروسه P1 اجازه داده شده که وارد CS شود اما در آنجا مرده است. پس از فعال شدن اولین تایمر نگهبان، t7، t8، و t9 زمان‌هایی هستند که دارای پیغام “AYA” می‌باشند. و پس از دومین تایمر نگهبان، بردار از t10 تا t11 برای پیغام “OK” است، چرا که P2 پیغام “REQUEST” را به P3 ارسال کرده است. در موارد بهبود یافته نیازی به این کار نیست، چرا که P2 قبلا این پیغام را دریافت کرده است.
شکل ‏۳‑۳- مشابه شکل ۳-۲، اما P1 زنده است ]۶۵[
شکل ۳-۳ همانند شکل ۳-۲ است، اما در اینجا P1 زنده بوده و برای مدتی طولانی در CS فعال باقی می‌ماند. این شکل‌ها نشان می‌دهند که وقتی دو پروسه در حالت رقابت، در دو مورد مختلف یک منبع یکسان را می‌خواهند که دارای یک CS است چه اتفاقی می‌افتد: در مورد اول، وقتی هر پروسه‌ای که در CS قرار دارد می‌میرد، و مورد دوم وقتی پروسه‌ای که در CS است هنوز زنده بوده و کارش ادامه دارد.
در ]۶۶[ یک الگوریتم عادلانه برای حل انحصار متقابل سیستم‌های توزیع شده با بهره گرفتن از گذر پیام‌های غیرهمزمان ارائه شده است. در این الگوریتم برای برقراری عدالت و بالا بردن رضایت در دسترسی به ناحیه بحرانی ترتیب اولویت را کاهش و از برچسب‌های زمانی Lamport استفاده نموده است. این الگوریتم برای هر دسترسی به ناحیه بحرانی نیاز به انتقال n-1 تا ۲(n-1) پیام دارد که سبب بهبود الگوریتم Ricart-Agrawala می‌شود. در واقع، تعداد پیام‌ها برای دسترسی به ناحیه بحرانی ۲(n-1)-x است که x تعداد درخواست‌هایی است که بطور همزمان با درخواست جاری ارسال شده است. پیچیدگی پیام‌ها را با بهره گرفتن از درخواست و پاسخ‌های چندگانه در رابطه با درخواست‌هایی که همزمان انجام می‌شود کاهش داده است. الگوریتم این روش در شکل ۳-۴ نشان داده شده است.
الگوریتم‌های ارائه شده برای مسئله انحصار متقابل باید فاقد گرسنگی و بن‌بست باشند. الگوریتم‌های مبتنی بر توکن دسته‌ای دیگر از الگوریتم‌های انحصارمتقابل هستند. در واقع توکن یک پیام الویت‌دار و خاص است. به‌صورت ساده می‌توان گفت هر پراسسی که این پیام را دریافت کند، می‌تواند وارد ناحیه بحرانی خود شود. چون فقط یک توکن در کل سیستم وجود دارد و فقط دارنده توکن می‌تواند وارد ناحیه بحرانی خود شود به همین علت با وجود توکن در سیستم، انحصار متقابل تضمین شده خواهد بود.
شکل ‏۳‑۴- الگوریتم انحصار متقابل ارائه شده در ]۶۶[
در نحوه انتقال توکن به پراسس بعدی نیز تفاوت‌هایی بین الگوریتم‌های مختلف وجود دارد اگر پراسس‌ها به‌صورت منطقی در ساختاری قرار گرفته باشند در این حالت بر طبق همان ساختار توکن انتقال داده خواهد شد به‌عنوان مثال اگر ساختار حلقه‌ای به‌صورت منطقی تشکیل شده باشد توکن به پراسس بعدی در این حلقه تحویل داده خواهد شد. روش دیگر این است که دارنده توکن، یکی از پراسس‌هایی که درخواست ورود به ناحیه بحرانی را دارد انتخاب کرده و توکن را برای آن پراسس ارسال می‌کند.
نمونه معروف از الگوریتم‌های مبتنی بر توکن، الگوریتم توکن حلقه‌ای^[۱۵۴] است]۶۷[. در این الگوریتم پراسس‌ها به‌صورت حلقه^[۱۵۵] منطقی چیده می‌شوند. ممکن است توپولوژی واقعی شبکه به‌صورت bus یا هر توپولوژی دیگری باشد ولی به‌صورت منطقی یک حلقه تشکیل می‌شود و هر پراسس فقط می‌داند پراسس بعدی او در این حلقه چه پراسسی است.
زمانی که حلقه ساخته می‌شود توکن به پراسس شماره صفر داده شده و توکن دست‌به‌دست در این حلقه می‌چرخد و هر پراسسی که قصد ورود به ناحیه بحرانی خود را داشته باشد با تصاحب توکن وارد ناحیه بحرانی می‌شود و بعد از خروج از ناحیه بحرانی توکن را به پراسس بعدی می‌دهد و اگر پراسسی نیازی برای دسترسی به ناحیه بحرانی خود نداشته باشد در صورت تصاحب توکن بلافاصله توکن را به پراسس بعدی می‌فرستد.
برای جلوگیری از گرسنگی زمانی که دارنده توکن از ناحیه بحرانی خود خارج می‌شود حتماً باید توکن را به پراسس بعدی تحویل دهد حتی در صورت نیاز دوباره برای ورود به ناحیه بحرانی. به‌عبارت دیگر با هر بار تصاحب توکن حداکثر یک‌بار می‌توان وارد ناحیه بحرانی شد و اگر دوباره قصد ورود به ناحیه بحرانی داشته باشد باید صبر کند تا توکن یک دور در حلقه زده و دوباره به‌دست پراسس برسد.
به‌سادگی مشاهده می‌شود که الگوریتم درست کار می‌کند. چون فقط یک توکن وجود دارد و فقط دارنده توکن می‌تواند وارد ناحیه بحرانی خود شود بنابراین انحصار متقابل محقق خواهد شد و همینطور هیچ بن‌بستی در سیستم رخ نخواهد داد. چون هیچ پراسسی منتظر پاسخ از پراسس دیگر نخواهد بود. توکن دست‌به‌دست منتقل خواهد شد و هر پراسسی نیز به اندازه محدودی مالک توکن خواهد بود و به همین دلیل گرسنگی هم نخواهیم داشت یعنی در زمان محدودی هر پراسسی که قصد ورود به ناحیه بحرانی را داشته باشد به این امر نائل خواهد شد.
در الگوریتم توکن حلقه‌ای نمی‌توان مقدار دقیقی برای تعداد پیام ارسال شده به ازای هر دسترسی به ناحیه بحرانی مشخص کرد ولی می‌توان حدبالا و پایین آن را در بهترین حالت و بدترین می‌توان مشخص کرد. در بهترین حالت اگر تمام پراسس‌ها نیاز به دسترسی به ناحیه بحرانی خود را داشته باشند به صورت میانگین یک پیام برای هر دسترسی به ناحیه بحرانی نیاز است و آن یک پیام نیز همان ارسال توکن به پراسس بعدی است و در بدترین حالت می‌توان اینگونه در نظر گرفت که هیچ پراسسی قصدی برای ورود به ناحیه بحرانی خود نداشته باشد و در این حالت توکن به‌صورت دائم در حال چرخش در حلقه است و بینهایت پیام ارسال خواهد شد. بنابراین یکی از مشکلات این الگوریتم این است که در بار کم، بینهایت پیام (توکن) منتقل می‌شود یعنی حالتی که توکن در حال چرخش در حلقه است و هیچ پراسسی قصدی برای ورود به ناحیه بحرانی خودش ندارد.
یکی از الگوریتم‌های معروف مبتنی بر توکن در مسئله انحصار متقابل توسط Suzuki ]68[ ارائه شده که توسط Ricart نیز در ]۶۹[ ارائه شده است که هر دو مقاله تقریباً یک الگوریتم را ارائه می‌دهند.
در این الگوریتم بک توکن وجود دارد که در حقیقت یک آرایه Token[n] است که خانه شماره K آن، شماره ترتیبی^[۱۵۶] پراسس K را در آخرین دسترسی به توکن نشان می‌دهد. علاوه بر توکن هر کدام از پراسس‌ها آرایه‌ای در اختیار دارند که خانه شماره K ارائه نشان‌دهنده شماره ترتیبی آخرین درخواستی است که از پراسس K به پراسس جاری رسیده است. به این آرایه، آرایه درخواست Request[n] گفته می‌شود.
الگوریتم به این ترتیب عمل می‌کند: در شروع کار به یکی از پراسس‌ها به‌صورت اختیاری توکن داده می‌شود. زمانی که پراسس j قصد ورود به ناحیه بحرانی خود را داشته باشد اگر صاحب توکن باشد بلافاصله وارد ناحیه بحرانی خود می‌شود در غیراین‌صورت شماره ترتیبی خود را یک واحد افزایش داده و یک پیام همراه با شماره ترتیبی جدید ساخته و به تمام پراسس‌ها ارسال می‌کند و منتظر دریافت توکن می‌شود. از طرفی وقتی یک پراسس از ناحیه بحرانی خود خارج می‌شود می‌بایست توکن را به پراسسی که درخواست ورود به ناحیه بحرانی دارد ارسال کند. پراسس این کار را با جستجو در آرایه درخواست خود به ترتیب j+1,J+2,…,n,1,2,…,j-1 انجام می‌دهد. توکن به پراسس k که در اینجا k اولین خانه آرایه درخواست request[k] است که شماره ترتیبی ذخیره شده در آن از شماره ترتیبی ذخیره شده در خانه معادل آن در توکن token[k] بزرگتر باشد، ارسال خواهد شد. یعنی وقتی که request[k]>token[k] باشد در این حالت توکن برای پراسس k ارسال خواهد شد.
این معادله نشان‌دهنده این مطلب است که درخواست پراسس k بعد از آخرین دسترسی به توکن ارسال شده است. یعنی پراسس k هم اکنون منتظر دریافت توکن است. در حقیقت استفاده از این فرمول به این علت است که پراسس دارنده توکن تشخیص دهد درخواست پراسس k معتبر است یا اینکه قدیمی است و پراسس k بعد از درخواستش به توکن دسترسی پیدا کرده و الان درخواستی برای دسترسی به ناحیه بحرانی خود ندارد.
علت وجود شماره ترتیبی در این الگوریتم هم همین موضوع است چون که در این الگوریتم درخواست به تمامی پراسس‌ها ارسال می‌شود و ترتیب از قبل مشخص شده برای تصاحب توکن وجود ندارد برای همین دلیل وقتی پراسسی درخواستی می‌دهد و بعد صاحب توکن می‌شود، درخواستش هنوز در بقیه پراسس‌ها موجود است و ممکن است به اشتباه دوباره توکن را برای پراسس مورد نظر ارسال کنند. برای جلوگیری از این اشتباه از شماره ترتیبی و فرمول گفته شده استفاده می‌شود.
در این الگوریتم زمانی که پراسسی بخواهد به ناحیه بحرانی خود دسترسی پیدا کند اگر دارنده توکن باشد هیچ پیامی ارسال نخواهد کرد و می‌تواند بلافاصله وارد ناحیه بحرانی خود گردد ولی اگر دارنده توکن نباشد باید n پیام (n-1 پیام برای ارسال درخواست به پراسس‌های دیگر و یک پیام برای دریافت توکن) انتقال داده شود.
الگوریتم دیگر، الگوریتم Mizuno ]70[ است. در در این الگوریتم تلفیقی از الگوریتم Suzuki ]68[ و quorurn agreements صورت گرفته است. در واقع این الگوریتم با بهره گرفتن از quorurn agreements، گروه‌هایی ساخته است که هر پراسس برای دسترسی به ناحیه بحرانی خود فقط به اعضای همان quorurns که عضو آن است درخواست خود را ارسال می‌کند.
یک quorurn agreements(Q,Q^-1) دو مجموعه‌اند که اعضای آن‌ها زیر مجموعه‌هایی از پراسس‌های موجود در سیستم هستند. به بیان ساده کل پراسس‌ها در گروه‌های مجزایی تقسیم می‌شوند که به مجموعه این گروه‌ها Q گفته می‌شود. به مجموعه پراسس‌های هم گروه با پراسس i در مجموعه Q، R_i گفته می‌شود.Q^-1 شامل مجموعه‌هایی است که هر کدامشان با تمام مجموعه‌های Q دارای اشتراک هستند. به مجموعه پراسس‌های هم گروه با پراسس i مجموعه Q^-1، A_i گفته می‌شود.
این الگوریتم بر مبنای الگوریتم Suzuki طراحی شده است و همانند الگوریتم Suzuki هر کدام از پراسس‌ها دارای آرایه PN_i هستند که RN[j] مشخص کننده تعداد درخواست‌هایی است که پراسس j ارسال کرده است و پراسس i از آن مطلع است. توکن نیز یک پیام ویژه است که حاوی آرایه LN است که LN[j] مشخص کننده بزرگترین شماره ترتیبی در درخواست‌هایی است که تا به حال j ارسال کرده است. Token-Q صف توکن است که در آن شماره پراسس‌هایی قرار می‌گیرد که توکن باید به آن‌ها ارسال شود.
در این الگوریتم زمانی که پراسس i قصد ورود به ناحیه بحرانی داشته باشد و توکن نیز در اختیار خودش نباشد، یک پیام درخواست که حاوی RN_i خودش است به تمام پراسس‌هایی که در R_i هستند ارسال می‌کند. در بهترین حالت اگر توکن در اختیار یکی از این پراسس‌ها باشد. توکن را به پراسس درخواست کننده ارسال می‌کند. در هر صورت پراسس منتظر دریافت توکن می‌شود. زمانی که توکن به پراسس i می‌رسد در ابتدا درخواست‌های رسیده از دیگر پراسس‌ها را در توکن قرار می‌دهد. برای اینکه پراسس i بفهمد کدام درخواست جدید است و در توکن موجود نیست از فرمول LN[j]<RN_i[j] استفاده می‌کند. برای هر پراسسی که معادله برقرار باشد LN[j] را برابر RN_i[j] قرار داده و j را درون صف Token-Q قرار می‌دهد. برقرار بودن معادله بدین معنی است که پراسس درخواستی داده است و این درخواست در پراسس i نگهداری می‌شده است و این درخواست در توکن موجود نیست و در توکن اعمال نشده است زیرا شماره ترتیبی موجود در توکن برای پراسس j کمتر از شماره ترتیبی موجود در پراسس i است. وقتی توکن به پراسس i می‌رسد علاوه بر به‌روزرسانی LN و صف توکن یک پیام به اسم ACQUIRED به تمام پراسس‌هایی که در A_i خود موجود است ارسال می‌کند و با ارسال این پیام به پراسس‌های مجموعه A_i اطلاع می‌دهد که صاحب توکن شده است و پیام ACQUIRED حاوی یک کپی از LN به نام LN_i است. تمام پراسس‌هایی که ACQUIRED را دریافت می‌کنند بر اساس LN_i موجود در آن درخواست‌های جدیدی که نگهداری می‌کردند را تشخیص داده و طی پیامی درخواستی آن‌ها را به پراسس i برمی‌گردانند و پراسس i آن درخواست‌ها در توکن قرار می‌دهد.
کارایی این الگوریتم به نحوه انتخاب quorum agreement بستگی دارد. براساس پروتکل درخت دودویی ارائه شده در ]۷۱[ حداقل سایز R_i و A_i، log n است. پس تعداد پیام جابه‌جا شده O(Log n) است. تعداد پیام جابه‌جا شده بین (|R_i|-1)+(|A_i|-1)+1 و (|R_i|-1)+2(|A_i|-1)+1 است.
یک راه‌حل ساده برای CTP^[157] به‌کارگیری یک دربان^[۱۵۸] برای جلسه‌ها خواهد بود (در پیاده‌سازی دربان می‌تواند یک پراسس مجزا در کنار پراسس‌هایی که قرار است انحصار متقابل گروهی بین آن‌ها رعایت شود، باشد). دربان به‌صورت دوره‌ای وضعیت فیلسوف‌ها را بررسی کرده و در صورتی که فیلسوفی علاقمند به حضور در جلسه تحت‌نظر دربان را داشته باشد اقدامات لازم برای ورود فیلسوف به جلسه را انجام می‌دهند. به‌عنوان مثال اگر اتاق جلسه خالی باشد دربان می‌تواند اولین فیلسوف منتظر را به اتاق فراخوانده و جلسه درخواستی فیلسوف را برگزار کند و هر فیلسوفی که درخواست ورود به جلسه جاری را داشته باشد، وارد اتاق جلسه می‌شود و فیلسوف‌هایی که منتظر ورود به جلسه دیگری هستند در صف قرار می‌گیرند. در این صورت دربان می‌تواند یکی از فیلسوف‌ها را به عنوان فیلسوف مرجع انتخاب کرده و تا زمانی که فیلسوف مرجع در جلسه حضور دارد هر فیلسوفی می‌توان به هر تعداد ممکن وارد جلسه شده و جلسه را ترک کند. بعد از اینکه فیلسوف مرجع اتاق جلسه را ترک کرد (به‌عبارت دیگر از جلسه جاری خارج شد) اگر درخواستی برای برگزاری جلسه دیگری وجود داشت در این حالت در ورودی اتاق جلسه بسته خواهد شد و هیچ فیلسوف دیگری به اتاق جلسه راه داده نمی‌شود و منتظر می‌شویم تا فیلسوف‌های حاضر در اتاق جلسه، کارشان به اتمام رسیده و اتاق جلسه را ترک کند و یا خروج آخرین فیلسوف از اتاق جلسه، جلسه جاری به اتمام رسیده و جلسه دیگری جایگزین خواهد شد. اما اگر فیلسوف مرجع از جلسه خارج شده و فیلسوف دیگری نیز منتظر ورود به جلسه دیگری نباشد. در این حالت از بین فیلسوف‌های حاضر در جلسه جاری یکی به عنوان فیلسوف مرجع انتخاب می‌شود. با این روند تاخیر محدود تامین خواهد شد زیرا فیلسوف مرجع، مقدار زمان محدودی در جلسه حضور خواهد داشت و هم اینکه درجه همروندی بینهایت به دست خواهد آمد. الگوریتم کامل همراه با جزییات را در ]۷۲[ با عنوان CTP-C^[159] توضیح داده شده است. به راحتی می‌توان دید که الگوریتم CTP-C دارای درجه همروندی نامحدود است زیرا تا زمانی که فیلسوف اصلی در جلسه حضور دارد بقیه فیلسوف‌ها به تعداد نامحدود و تکراری می‌توانند وارد جلسه شده و آن را ترک کنند.
با به‌کارگیری یک دربان برای هرکدام از جلسه‌ها می‌توان الگوریتم CTP-C را کمی توزیع‌شده کرد. برای تحقق انحصار متقابل بین دربان‌ها، از توکن استفاده خواهد شد و توکن بین دربان‌ها جابه‌جا خواهد شد و دربان‌ها قبل از هماهنگی و اعطای حق ورود به فیلسوف‌ها باید توکن را به دست بیاورد و توکن را تا زمانی که فیلسوف‌ها کاملاً از جلسه خارج نشده‌اند پیش خود نگه می دارد و پس از خارج‌شدن همه فیلسوف‌ها (اتمام جلسه جاری) توکن را به دربان بعدی تحویل می‌دهند. برای افزایش همروندی هر دربان اجازه ورود و خروج مکرر به هر فیلسوف را خواهد داد و برای اینکه با این کار ویژگی تاخیر محدود نقص نشود همیشه یک فیلسوف به‌عنوان فیلسوف مرجع انتخاب خواهد شد. این الگوریتم نیز با نام ^[۱۶۰]CTP-SD در ]۷۲[ ارائه شده است. CTP-SD هم به‌علت استفاده از فیلسوف مرجع دارای درجه همروندی نامحدود است. چون از توکن برای انحصار متقابل در بین دربان‌ها استفاده شده است پیچیدگی تعویض به نوع الگوریتم توکن بستگی دارد و در بدترین حالت حتی ممکن است آن پیچیدگی‌ها بی نهایت باشد. CTP-SD نیز دارای معایبی است از جمله آن‌که اگر دربانی کند باشد و سرعت پردازش در آن پایین باشد، زمانی که توکن به او برسد و مشغول انجام عملیات برگزاری جلسه خودش شود، به تبع کل سیستم را نیز کند می‌کند و تبدیل به گلوگاه خواهد شد و کارایی کل سیستم را کاهش می‌دهد و همچنین زمان زیادی برای تعویض طول خواهد کشید. از معایب دیگر این الگوریتم اینکه اگر m (تعداد جلسه‌ها) نسبت به n (تعداد پراسس‌ها) خیلی بیشتر باشد تعداد زیادی دربان خواهیم داشت که کارایی کل سیستم را پایین خواهند آورد و اگر n نسبت به m خیلی بیشتر باشد به علت تعداد کم دربان‌ها، بار کاری زیادی بر روی دربان‌ها واقع می‌شود و دربان‌ها تبدیل به گلوگاه سیستم می‌شوند.