"Race Condition" Çözümleri

Herkese iyi akşamlar,

Bugün farklı bir kayıt girmek istiyorum. İşletim Sistemlerinden gideceğiz. Konumuz Race Condition'ı Çözmek...
Kısaca Race Condition ne demek onu hatırlayalım:ortak alana hangi process'in önce gireceği, oradaki değeri kimin alacağı ve nasıl değiştireceği gibi sorunlar en temel anlamda race condition'dır. İsminden belli zaten, process'ler birbirleriyle yarış halindedirler, alana girebilmek için. İşte bunun önüne nasıl geçebiliriz? Bugünkü konumuz başlıyor...

İki ana başlık altında inceleyebiliriz:

• Busy Waiting
• Sleep and Wakeup

Busy Waiting'de sürekli olarak ortak alan hazır mı değil mi/boş mu dolu mu gibi kontroller yaparız. Busy Waiting de kendi içinde 5 maddede incelenebilinir:

1. Disabling Interrupts
2. Lock Variables
3. Strict Alternation
4. Peterson's Solution
5. TSL(Test and Set Lock) Instruction

"Disabling Interrupts"ta bir process ortak alana girdiğinde tüm "interrupt"lar pasifleştirilir. Tüm sistem bloke edilmiştir. Birden çok process varsa da, bir tanesini pasifleştirirsin, diğerleri çalışmaya devam eder. Bloke etmeye dayalı olan bu metot, Busy Waiting'in en kötüsüdür. Benzetmek gerekirse, hasta kanseri yener ama yan etkileri kanserden beter eder.

Lock Variables'a gelelim. Lock adında ortak bir değişken yaratırız. Kritik bölgeye girecek olan process "lock"a bakar. Lock=0(sıfır) ise girer, içerisi boş demektir. Lock=1 ise girmez, içerisi dolu demektir. Lock=0 iken bir process içeri girerse, Lock değeri 1 olur ve diğer "process"ler bu değerin sıfıra dönmesini beklerler. Ancak Lock'ın kendisi "race condition"a sebep olur.
Şöyle bir senaryo üzerinden anlatalım: A process'i lock değerine bakarken sleep moda düşsün. Ardından B process'i de lock'a baksın, boş olduğunu görsün ve o da sleep moda düşsün. Akabinde A process'i uyansın ve haliyle daha önce boş olduğunu gördüğü alana girsin. Ardından da B process'i uyansın ve o da en son kritik bölgenin boş olduğunu gördüğünden, alana girmeye teşebbüs etsin... The End! :)

Strict Alternation ise Lock Variables'ın aşağı yukarı aynısı. Onda da 1 ve 0 kontrolü yaparsınız. Bunda şu var: kritik alanın sıfıra dönmesini bekleyen process yavaş davranırsa, alana girememe ihtimali var. Örneğin büyük çapta I/O yapan bir process ise "rest in peace". :)

Gelelim Peterson's Solution'a. Bu yöntemde de bir dizi oluşturulur ve her process için dizide bir eleman tutulur. Her process dizide kendisi için tutulan variable'ı diğer yöntemlerdeki gibi 1 veya 0 yapar. Örneğin A process'i alana girdiğinde dizideki değişkenini 1 yapar. B process'i de diziye girememiş olur. A process'inin değişkeni sıfır olmadan B kendi değişkenini 1 yapamaz. Ancak aynı sorunlar bu yöntemde de mevcuttur.

TSL Instruction ise son Busy Waiting yöntemimiz. Bunda test ve lock işleri tek bir operasyonda olur. Donanımsal bir destekle yürütülen bu yöntem şöyle işler: A lock'a baktı. Sıfır olduğunu gördü. Önceki yöntemlerde sleep moda düşebiliyordu. Burda o engellenmiş. Yani A process'i için o değer 1'e çekilmeden, A process'ini sleep ettirmiyoruz.
Herşey muhteşem oldu diyorsanız, yanılıyorsunuz. Çünkü biz A process'inin sleep olmadan lock değerini bir yaptırdıktan sonra, lock sıfıra çekilinceye kadarB process'i bekliyor. Yani CPU zamanı boşa gitmiş oluyor. Ki bu tüm Busy Waiting yöntemlerinin ortak sorunu aslında. Peki ne yapabiliriz? İşte ikinci maddemiz... :)

Sleep And Wakeup yöntemi ile, bir process kritik alana girdiyse, ardından başka bir process de alana girmek istiyorsa, o istekli arkadaşı bloke ediyoruz. Yani içerisinin boşa düşmesini beklerken, CPU vakti de boşa harcanmamış oluyor zatı şahaneleri için. İçerisi boşa düştüğünde wakeup mesajı gönderiyoruz ve kendilerini uyandırıyoruz. Yalnız bu yöntemimizin de ufak mı ufak bir kusuru var. Ya "wakeup" mesajı kaybolursa... İşte böyle bir durum olursa, o process bir daha aramıza katılamaz.

Böylelikle Race Condition'a karşı geliştirilen yöntemleri görmüş olduk.

Görüşmek üzere..