Bu yazıdan sonra terimleri Türkçeleştirmemeye karar verdiğimi de belirtmek isterim. Bu yüzden her ingilizce terimi içeren bir sözlük yazıya dahil edilecektir.

Sözlük:

• Utilization: İşlemcinin, işlem yaptığı süre, bu sürenin yüksek olması, donanımdan maksimum verim alındığını gösterir.
• Throughput: Birim zamanda bitirilen işlem sayısıdır. Örnek: iş/saniye
• Service Time: Servis süresi, bir cihazın, gelen isteği çözümlemesi için geçen süre.
• Queueing Time: Kuyruk süresi, alınacak hizmet için kuyrukta beklenen süre.
• Response Time: Yanıt süresi, kullanıcı işlemine sistemin verdiği tepki süresidir.

Üretici ve Tüketici Problemine Derinlemesine Bakış:

Daha önce üretici ve tüketici probleminden (producer and consumer problem) bahsetmiştim. Bu bölümde daha detaylı kodlar vererek derinlemesine inceleyip, işlemler arası senkronizasyonu anlamaya çalışacağız.

Üretici, veri üreten uygulamaya verilen isimdir. Bu uygulamanın görevi belli veri türünde veri üretmektir. Kullanılan veri yapılarını tanımlayalım.

#define BUFFER_SIZE 10

typedef struct {
	DATA 	data;
} item;

item	buffer[BUFFER_SIZE];
int	in=0;		//Yeni girdinin buffer'daki lokasyonu
int	out=0;		//Tüketilecek verinin buffer'daki lokasyonu
int	counter=0;	//Buffer'da kaç odanın kulllanıldığı

Üretici:
Üretici işlem, tüketici işlemin tüketmesi için işlem üretir. Ancak burada önemli olan bounded (sınırlı) buffer’ı aşmayacak kadar veri üretmektir. Kodunu inceleyelim.

item    NextProduced;

while (TRUE)
{
    while (counter == BUFFER_SIZE);
    buffer[in] = Nextproduced;
    in = (in+1) % BUFFER_SIZE;
    counter++;    //Bu kısma birazdan değineceğiz, bu satır çok önemli...
}

Tüketici:

item    NextConsumed;

while (TRUE)
{
    while (counter == 0);
    NextConsumed = buffer[out];
    out = (out + 1) % BUFFER_SIZE;
    counter--;
}

Burada producer kodundaki ‘counter++;’ kodu çok önemli. Bu kodun assembly karşılığını yazacak olursak:

MOV AX, Counter
INC AX
MOV Counter, AX

şeklinde olacaktır. Bu durumda eğer üretici işlemi çalışırken, preemption mekanizması devreye girerse ve “MOV Counter, AX” işlemi çalışmadan Context switching gerçekleşirse, ve context switch olduktan sonra producer işlemi çalışırsa, bu durumda counter değeri bir eksik olarak hesaplanacaktır. Bu da buffer overflow’a (buffer taşması) neden olabilir. Tehlikeli bir durumdur.

Bu durumda critical section’dan (kritik bölge) bahsedebiliriz.

Critical Section: Kodun herhangi bir yerinde context switching olup olmamasına göre işlemin sonucu değişebiliyorsa, ve bu işlemin sonucu önemliyse, bu bölgede context switching olmaması istenir. Bu bölgeye critical section denir. Bu bölgede aynı anda bir kod parçası çalışabilir. Başka bir kod parçası çalışamaz.

Bir critical section aşağıdaki bölgelerden oluşur.

• Entry Section: Kodun critical section’a girmek için istekte bulunduğu bölümdür.
• Critical Section: Aynı anda yalnızca bir kod parçasının çalıştığı bölgedir.
• Exit Section: Critical Section’dan çıkış yapılan bölümdür. Buradan sonra ayrılmış alanları diğer işlemler kullanabilir.
• Remainder Section: Critical Section’dan sonraki kod parçalarıdır.

Critical Section Şu Üç Özelliği Sağlamalıdır:

• Mutual Exclusion (MUTEX): Birden fazla işlen critical section’da aynı anda çalıştırılmamalıdır.
• Progress: Eğer critical section’da hiç bir işlem yoksa ve bunların hiç birisi remainder section da değilse, hangi işlemin critical section’a gireceğine sınırlı sürede karar verilmelidir.
• Bounded Wait: Critical Section’a girmek isteyen bütün işlemler eninde sonunda critical section’a girmelidir.

Critical Section Kod Örneği:

do
{
	while (turn !=i );
	/*CRITICAL SECTION*/
	turn = j;
	/* REMAINDER SECTION */
} while (TRUE);

NOT: Buradaki kod parçalarıda “i” çalışmakta olan process’i, “j” ise sırada bekleyen process’i ifade eder.

• ALGORITMA 1:

do
{
	while (turn !=i );
	/*CRITICAL SECTION*/
	turn = j;
	/* REMAINDER SECTION */
} while (TRUE);

Bu kod parçasında çalışan process, çalışmasını bitirdikten sonra diğer process’in critical section a girebilmesi için turn değişkenine, diğer process’in id’sini atar. Bu durumda 2 den fazla process’in aynı critical section’a giremeyecek olması bir yana, diğer taraftan “progress ve bounded wait” özellikleri sağlanmaz. Çünkü 1. process, sırayı 2. process’e devreder ama sıra 2. process’dan önce tekrar 1. process’e gelebilir.

• ALGORITMA 2:Bu algoritmada her process’e ait birer bayrak (flag) vardır. Bu flag critical section’da olup olmadığını gösterir. Critical Section’a girmek için diğer process’lerin flag leri kontrol edilmelidir.

Paylaşılan Değişkenler:

boolean flag[2]=false;

Şimdi algoritmaya bakalım.

do
{
        flag[i] = TRUE;
        while (flag[j]);
        /* CRITICAL SECTION */
        flag[i] = FALSE;
        /* REMAINDER SECTION */
} while (TRUE);

Bu algoriyı inceleyecek olursak, iki process ‘de critical section da değilken, process lerden bir tanesi critical section’a girmek isterse ilk önce flag değişkeni TRUE olacaktır. Tam bu sırada context switching gerçekleşir ve 2. process de critical section’a girmek üzere flag değişkenini TRUE yaparsa, bu durumda 1. koşul sağlanmaz ve DEADLOCK oluşur. DEADLOCK kavramını bu yazının ilerleyen bölümlerinde açıklayacağız ama kısaca bahsetmek gerekirse, bu örnekte bir paylaşılan alandaki veriyi birden fazla process’in beklemesi ve hiç birisinin alamaması durumu olarak karşımıza çıkar.

• ALGORITMA 3: Bu algoritmada, her bir process critical section’a girmek için istek flag’ini işaretler daha sonra diğer process’in critical section’a girmesi için flag’i değiştirir. Algoritması ile daha iyi anlaşılacaktır.

Paylaşılan Değişkenler:

boolean flag[2];
flag[0]=FALSE;
flag[1]=FALSE;

Kod:

do
{
        flag[i]=TRUE;
        turn = j;
        while (flag[j] && turn == j);
        /* CRITICAL SECTION */
        flag[i] = FALSE;
        /* REMAINDER SECTION */
} while (TRUE);

Bu algoritmayı incelediğimizde deadlock oluşmadığını görüyoruz. Ancak 1. şartı da sağlamıyor. Çünkü, bir process’in critical section’a girebilmesinin şartı, diğer process’in “ENTER SECTION”a gelmesini gerektiriyor. Bu da zaman kaybı anlamına geliyor.

BU SORUNLARIN ÇÖZÜMLERİ:

Bu sorunların çözümü donanımsal olarak mümkün olabiliyor. Bu çözümler bazı özelliklerin sağlanmasını gerektirir.
Bu özellikler:

• bölünemez instruction’lar (assembly kod satırları)
• atomik load, store ve test instruction’ları, eğer store ve test işlemi eşzamanlı olursa, test işlemi, bir register (yazmaç) ın eski değerini de, yeni değerini de alabilir.
• İki farklı atomik instruction, eğer eşzamanlı çalıştırılsa bile sıralı çalışıyor gibi davranmalıdır.

Donanımsal Çözümler:

• Kesmeleri İptal Etmek (Disabling Interrupts): Bu yöntemde critical section’a girildiğinde donanımsal kesmeler iptal edilir, işlemci context switching yapmak için kesme kullandığından, kesmeler geçici bir süreliğine iptal edilirse, context switching gerçekleşmez. Böylece yukarda belirtilen sorunlar oluşmaz. Ancak bunun başka bir sorunu vardır. Bu da, critical section’a giren process kendi isteği ile critical section’dan ayrılmazsa preemption yapılamaması olarak kendini gösterir. Bu durumda tüm yönetim işletim sisteminin elinden alınır ve eğer critical section’daki işlem bir şekilde critical section’dan çıkmazsa tüm bilgisayar yanıt vermeyi durdurur.
• 
  Atomik Test and Set: Eğer bir mutex’in değeri atomik olarak test edilip değer atanırsa, ve sadece bu işlem atomik olursa, bunun için işlemcide özel instruction bulunursa, bu işlem sırasında context switching olmaz. Daha önceki örneklerde bu işlemin en az 3 instruction ile yapıldığını gördük ve bu işlemler sırasında context switching olabiliyordu.

Semaphore (Semafor):

Semaforlar, mutex’den daha karmaşık yapıları modellemek için kullanılırlar. Djikstra tarafından geliştirilmiştir. Bir critical section’a sadece istenen process’lerin erişebilmesini garanti eden atomik yapıda fonksiyonlardan ve korunan değişkenden oluşur. Semaforlar binary (ikili) veya counting (sayaç) semaphore olarak ikiye ayrılır. Binary semaphore, mutex’e çok benzerken, counting semaphore bir critical section’a belli sayıya kadar process’in ulaşmasını sağlayan yapıdır.

Race Condition: Birden fazla process aynı critical section’a erişemk istiyorsa ve bu process’lerin sırası önemliyle, bir process’in bu alana önce ulaşması race condition’a neden olabilir. Daha önce bahsettiğimiz enter section’daki context switching, race condition’a örnektir.

P(Semaphore s)                      // Kaynağı Almak
{
  wait until s > 0, then s := s-1;
  /* Test işlemi ve değerin azaltılması işlemi, RACE CONDITION oluşmaması için atomik yapıda olmalıdır. */
}

V(Semaphore s)  // Kaynağı Serbest Bırakmak
{
  s := s+1;   /* Atomik Olmalıdır. */
}

Init(Semaphore s, Integer v)
{
  s := v;
}

Burada kaynak ayırmak için s değerinin 0′dan büyük olması gerekir. Eğer 0′a eşitse, Busy Wait (Meşgul Bekleme) yapar. Bu durumda bir döngü sürekli çalışır ancak bir iş yapmaz. Sadece Critical Section’a giriş için onay bekler. Eğer Aynı anda birden fazla process’in bir critical section’a erişebilmesi isteniyorsa bu durumda Counting Semaphore kullanılır. Bu semaphore da “Init” fonksiyonuna en fazla kaç process’in aynı anda çalışması isteniyorsa o sayı argüman olarak verilebilir. Atomik olduğu için DeadLock ları engellemek daha kolaydır. Ayrıca birden fazla process’in aynı critical section’a girebilmesi gibi bir esneklik sağlar. Tabii bu durumda race condition oluşabilir. Race condition sonucu etkilemiyorsa tercih edilmelidir.