بخش بحرانی

کدهای و پروسه های مختلف ممکن است شامل متغیرهای یکسان یا سایر منابعی باشند که قرار است خوانده یا نوشته شوند اما نتایج آن ها بستگی به ترتیب رخ دادن عمل ها دارد. برای مثال، اگر متغیر x قرار باشد که توسط پروسه‌ی A خوانده شود و پروسه B قرار باشد که در متغیر x به طور همزمان بنویسد، آنگاه پروسه ی A ممکن است  مقدار قدیمی یا مقدار جدیدی از x به خود بگیرد.

Process A:

// Process A
.
.
b = x + 5;               // instruction executes at time = Tx
.

Process B:

// Process B
.
.
x = 3 + z;               // instruction executes at time = Tx
.

شکل ۱: گراف جریان که نشان دهنده ی لزوم وجود ناحیه ی بحرانی است

در مواردی این چنینی، وجود یک ناحیه بحرانی لازم است. در مثال بالا اگر لازم باشد که A مقدار به روز شده ی x را بخواند، آنگاه اجرای پروسه A و پروسه B به صورت همزمان ممکن است نتیجه دلخواه را ندهد. برای پیشگیری از این وضعیت، متغیر x توسط یک ناحیه بحرانی محافظت می شود. ابتدا B به ناحیه ی مورد نظر دسترسی پیدا می‌کند. هنگامی که عمل نوشتن مقدار توسط B تمام شد، A به ناحیه بحرانی دسترسی پیدا می کند و متغیر x قابل خواندن است. اگر به دقت کنترل شود که کدام متغیر در داخل و خارج ناحیه بحرانی تغییر پیدا کند، آنگاه از دسترسی همزمان به متغیر مشترک پیشگیری می شود. معمولاً ناحیه بحرانی زمانی استفاده می شود که یک برنامه چند ریسه ای باید چندین متغیر مرتبط را بروز رسانی کند و در عین حال هیچ ریسه ی مجزایی موجب تغییرات تنش زا در آن داده نشود. در یک وضعیت مشابه، ممکن است از ناحیه بحرانی در شرایطی استفاده کنیم که یک منبع مشترک، برای مثال یک پرینتر، فقط قابل دسترسی توسط یک پروسه در هر لحظه باشد.

پیاده سازی نواحی بحرانی در سیستم عامل های مختلف متفاوت است.

شکل ۲: قفل ها و نواحی بحرانی در ریسه های متعدد

معمولاً یک ناحیه بحرانی پس از یک زمان مشخص پایان می یابد[2] و یک ریسه، task یا پروسه مجبور است تا مدت زمان ثابتی را منتظر بماند تا وارد آن شود (انتظار محدود شده). برای اطمینان از استفاده ی انحصاری از نواحی بحرانی، برخی مکانیسم‌های همگام‌سازی در ورودی و خروجی برنامه مورد نیاز است. ناحیه بحرانی قطعه ای از برنامه است که نیاز به انحصار متقابل برای دسترسی به آن است. چنانکه در شکل ۲ نشان داده شده است،[3] در انحصار متقابل (mutex)، یک ریسه زمانیکه نیاز به دسترسی به منبع مشترک دارد، با استفاده از تکنیک های قفل کردن، ناحیه ی بحرانی را قفل می کند و سایر ریسه ها مجبورند تا منتظر بمانند تا نوبت آنها برای ورود به این ناحیه برسد. این فرایند زمانی که دو یا بیش از دو ریسه فضای حافظه مشابهی را در اشتراک دارند و می خواهند به یک منبع مشترک دسترسی پیدا کنند، مانع از تقابل می شود.

ساده ترین روش برای پیشگیری از هرگونه تغییر در کنترل پردازنده در داخل ناحیه بحرانی، پیاده سازی سمافور است. در سیستم های تک پردازنده ای، این هدف را می توان با غیر فعال کردن وقفه ها در هنگام ورود به ناحیه بحرانی ، اجتناب از فراخوانی هایی از سیستم که می تواند موجب تعویض زمینه(به انگلیسی: context switch) در حین حضور در داخل ناحیه شود و بازگرداندن وقفه به وضعیت قبل در هنگام خروج، عملی کرد. در این روش پیاده سازی، هر ریسه در حال اجرا که وارد هر ناحیه بحرانی در هر جایی از سیستم می شود مانع از این می‌شود که هر ریسه ی دیگر، از جمله یک وقفه، اجازه دریافت زمان پردازش در CPU پیدا کند. و همچنین به هیچ ریسه ی دیگری اجازه ورود به هیچ ناحیه بحرانی دیگری نمیدهد. این ممانعت تا زمانی ادامه پیدا می کند که ریسه ی  اولیه از ناحیه بحرانی خودش خارج شود.

این شیوه سفت و سخت را می توان با استفاده از سمافر ها بهبود بخشید. یک ریسه برای ورود به یک ناحیه بحرانی باید یک سمافور به دست آورد و زمانی که از ناحیه مذکور خارج می شود این سمافور را آزاد می کند. از ورود سایر ریسه ها به ناحیه بحرانی به صورت همزمان با ریسه ی اولیه پیشگیری می شود، اما ریسه های دیگر آزاد هستند تا کنترل واحد پردازش مرکزی را به دست گیرند و کد های دیگر را اجرا کنند، از جمله سایر بخش های بحرانی که توسط سمافور های متفاوت محافظت شده اند. قفل کردن سمافور نیز دارای محدودیت زمانی است تا از شرایط بن بست پیشگیری شود. این بن بست زمانی ایجاد می شود که یک قفل توسط یک پروسه به مدت نامتناهی در اختیار گرفته می شود و باعث توقف سایر پروسه هایی می شود که نیاز به استفاده از منابع مشترک محافظت شده توسط ناحیه بحرانی دارند.

• مسئله خوانندگان و نویسندگان
• مسئله غذا خوردن فیلسوف‌ها
• انحصار متقابل
• نشانبر

مشارکت‌کنندگان ویکی‌پدیا. «Critical section». در دانشنامهٔ ویکی‌پدیای انگلیسی، بازبینی‌شده در ۲۰ مارس ۲۰۲۱.

1. Raynal, Michel (2012). Concurrent Programming: Algorithms, Principles, and Foundations. Springer Science & Business Media. p. 9. ISBN 978-3642320279.
2. Jones, M. Tim (2008). GNU/Linux Application Programming (2nd ed.). [Hingham, Mass.] Charles River Media. p. 264. ISBN 978-1-58450-568-6.
3. Chen, Stenstrom, Guancheng, Per (Nov 10–16, 2012). "Critical Lock Analysis: Diagnosing Critical Section Bottlenecks in Multithreaded Applications". High Performance Computing, Networking, Storage and Analysis (SC), 2012 International Conference: 1–11. doi:10.1109/sc.2012.40. ISBN 978-1-4673-0805-2.
4. "RESEARCH PAPER ON SOFTWARE SOLUTION OF CRITICAL SECTION PROBLEM". International Journal of Advance Technology & Engineering Research (IJATER). 1. November 2011.
5. Dubois, Scheurich, Michel, Christoph (1988). "Synchronization, Coherence, and Event Ordering in Multiprocessors". Survey and Tutorial Series. 21 (2): 9–21. doi:10.1109/2.15.
6. Solihin, Yan (17 November 2015). Fundamentals of Parallel Multicore Architecture. ISBN 9781482211184.