İşletim Sistemleri (Operating Systems)

PROCESS SENKRONİZASYONU (PROCESS SYNCHRONIZATION)

Process Senkronizasyon Neden Gereklidir? Senkronizasyon temelinde, process’ler iki ayrı sınıfta ele alınır: Bağımsız Process (Independent Process): Bir process’in uygulanması, diğer process’lerin yürütülmesini etkilemez. Kooperatif Process (Cooperative Process) : Bir process’in uygulanması, diğer process’lerin yürütülmesini etkiler.

Process Senkronizasyon Neden Gereklidir? Cooperative process’ler diğer process’leri etkilerler veya diğer process’lerden etkilenirler. Cooperative process’ler paylaşılmış hafıza alanıyla veya dosya sistemleri ile veri paylaşımı yaparlar. Process senkronizasyon problemi, Cooperative Process’lerin yürütümünde ortaya çıkmaktadır çünkü kaynaklar bu yaklaşımda paylaşılmaktadır.

Process Senkronizasyon Neden Gereklidir? Senkronizasyon gereksinimi yalnızca çok işlemcili sistemlerinde ortaya çıkmaz. Eşzamanlı process yürütümünün olduğu tek işlemcili sistemlerde de gereklidir. Process’ler arasında kaynakları paylaşma yoluyla işbirliği yapılabilir. Paylaşılan kaynaklar : değişken, dosya, veri tabanı, gibi…. Process’ler birbirlerinin ürettiği verileri kullanabilir.

Process Senkronizasyon Neden Gereklidir? Paylaşılan kaynaklara process’lerin eşzamanlı erişimi, gerekli tedbir alınmadığında veri tutarsızlığına neden olabilir. Senkronize olmadan aynı veriye erişen ve değiştiren çoklu process’ler öngörülemeyen sonuçlara neden olabilir. Paylaşılmış veri üzerinde işlem yapan process’ler arasında veriye erişimin yönetilmesi gereklidir.

Yarış Durumu (Race condition) Process’lerin paylaşılan veriye erişmek için yarış içinde oldukları durumdur. Bir yarış durumu, iki veya daha fazla process, paylaşılan verilere eriştiğinde oluşur ve aynı anda veriyi değiştirmeye çalışırlar. Aynı değişkene çok sayıda process’in erişmesi durumunda sonuç değer erişim sırasına bağlı olarak değişebilir. Paylaşılan bir değişkene aynı anda sadece bir process’in erişimi sağlanmak zorundadır(process synchronization).

Yarış Durumu (Race condition) ---------------------------------------------------(1/4) int Count = 10; Process1 Process 2 Count++; Count--; ----------------------------------------------------(2/4) Process 1 Process 2 LOAD Reg, Count LOAD Reg, Count ADD #1 SUB #1 STORE Reg, Count STORE Reg, Count Count = ? 9, 10 or 11?

Yarış Durumu (Race condition) ------------------------------------------------------------------------------------------------------- (3/4) Process 1 Process 2 Instruction Register Memory LOAD 10 SUB 9 ADD 11 STORE

Yarış Durumu (Race condition) ------------------------------------------------------------------------------------------------------- (4/4) Process 1 Process 2 Instruction Register Memory LOAD 10 ADD 11 SUB 9 STORE

Yarış Durumu (Race condition) İki thread aynı anda bir işlemi yapmaya çalışırsa oluşabilecek durumu düşünelim. Örneğin, thread A ve thred B, her ikisi de bir counter değerini bellekten okusun; Counter değeri başlangıçta 17 olsun. Ardından thread A counter değerini bir arttırır ve 18'i belleğe yazar. Aynı zamanda, thread B counter değerini bir arttırır ve 18'i thread A dan hemen sonra belleğe yazar. Bu noktada, veri bozulmuştur. çünkü counter değeri 17'den iki kez arttıktan sonra hala 18 değerini tutmaktadır.

Yarış Durumu (Race condition) Bir process/thread paylaşılan bir kaynağa erişim başlamadan önce, başka bir process/thread çalışmasının paylaşılan kaynak üzerinde bitmiş olduğundan emin olmalıdır.

Kritik Bölge Problemi (Critical Section Problem) Program kodunun, paylaşılan kaynaklar üzerinde işlem yapılan kısmı Kritik Bölge (Critical Section) olarak adlandırılır. Kritik bölge, aynı anda yalnızca bir process tarafından erişilebilen bir kod kesimidir. Kritik bölge, paylaşılan değişkenleri içerir.

Kritik Bölge Problemi (Critical Section Problem) Paylaşılan veri değişkenlerinin tutarlılığını sağlamak için process’lerin kritik bölgeye erişiminde senkronize edilmeleri gereklidir. Bir process kritik bölgedeyse, başka bir process kritik bölgede olmamalıdır. Yani belirli bir anda sadece tek bir process kritik bölgesindeki kodu yürütebilir. Her process, kritik kod bölümüne girmek için izin istemek zorundadır.

Kritik Bölge Problemi (Critical Section Problem) Kritik bölge (critical section), paylaşılan değişkenleri içerir. Bir process kendi kritik bölgesini çalıştırırken diğer process’lerin kendi kritik bölgelerini çalıştırmamaları zorunludur.

Kritik Bölge Problemi (Critical Section Problem) Her process, ortak değişkenler, tablolar veya dosyalar üzerinde işlem yapan kritik bölgeye sahip olabilir. Kritik bölge, bir giriş bölümü (entry section) ve bir çıkış bölümü (exit section) arasında bulunur. entry section giriş izni için kullanılır.

Kritik Bölge Probleminin Çözümü (Solution to Critical-Section Problem) Kritik bölge sorununun çözümü aşağıdaki üç gereksinimi karşılamalıdır: Karşılıklı Dışlama (Mutual Exclusion) İlerleme (Progress) Sınırlı Bekleme (Bounded Waiting)

Kritik Bölge Probleminin Çözümü (1) Karşılıklı Dışlama (Mutual Exclusion) : Bir process kritik bölgede yürütülüyorsa, kritik bölgede başka hiçbir process yürütülmemelidir (kod bölümlerini kilitleyebilmek gerekir). Paylaşılan kaynaklara iki tür erişim yapılır: Yazma ve Okuma Yazmada karşılıklı dışlama olmalı Okuma için karşılıklı dışlama gereksiz

Kritik Bölge Probleminin Çözümü Karşılıklı Dışlama (Mutual Exclusion)

Kritik Bölge Probleminin Çözümü (2) İlerleme (Progress) : Kritik bölgede hiçbir process yürütülmüyorsa ve kritik bölgeye girmek isteyen başka process’ler mevcutsa, bir tanesinin kritik bölgeye girmesine izin verilir. Kritik bölgeye girecek process’lerin seçimi süresiz ertelenemez.

Kritik Bölge Probleminin Çözümü (3) Sınırlı Bekleme (Bounded Waiting) : Bir process kritik bölüme giriş izni istedikten sonra ve izin verildikten önceki aralıkta, kritik bölüme giriş izni verilen process sayısının sınır değeri vardır. Yani kritik bölgeye girmek isteyen bir process’in bekleme süresi sınırlandırılmalıdır.

Kritik Bölge Probleminin Olası Çözümleri Donanım Gerektirmeyen Yazılıma Dayalı Çözümler Donanıma Dayalı Çözümler Yazılım ve Donanıma Dayalı Çözümler

Donanım Gerektirmeyen Yazılıma Dayalı Çözümler Kesmelerin Aktif ve Pasif Yapılması : Bir process kritik bölgesine girince sistem kesmelere (interrupt) karşı kapatılarak diğer process’lerin ilgili kritik bölgesine girmesi engellenebilir ve kritik bölge işlemi tamamlanınca da tekrar kesmelere açılabilir. Böylece process kritik kısmını bitirene kadar CPU’yu kullanır ve başka bir process’in CPU’dan faydalanmasını engeller. Process 1 . . . kesmeler_pasif; toplam=toplam + degisim; kesmeler_aktif; Process 2 . . . kesmeler_pasif; toplam=toplam - degisim; kesmeler_aktif;

Donanım Gerektirmeyen Yazılıma Dayalı Çözümler Kesmelerin Aktif ve Pasif Yapılması : di; saniye1 = saniye; dakika1 = dakika; saat1 = saat; ei; di; saat = 0; dakika = 0; saniye = 0; ei; di : kesme devre dışı, ei : kesme kullanılabilir.

Donanım Gerektirmeyen Yazılıma Dayalı Çözümler Kesmelerin Aktif ve Pasif Yapılması : Bu yöntemin en önemli sakıncası, kesme düzeneğinin denetimini sistemde çalışan çok sayıda process’e, özellikle çekirdek katmanı dışındaki process’lere de dağıtmasıdır. Kesme düzeneğinin tutarlı yönetimi güvenli bir işletim için vazgeçilmez bir gerekliliktir. Sistemin kesmelere açılıp kapatılması gibi temel bir aracı her düzeyden (ayrıcalıklı ve sıradan) process’in insiyatifine bırakmak, kesmelerin yönetimini bu process’lerle paylaşmak anlamına gelir.

Donanım Gerektirmeyen Yazılıma Dayalı Çözümler Kesmelerin Aktif ve Pasif Yapılması : Kritik kesimlerin kesilmelere kapalı olarak işletilmesi CPU’nun tüm dış uyarılara kapatılması anlamına gelir. Bu da sistemin genel başarımını olumsuz yönde etkiler. Bu yöntem işlemcinin birden fazla process’i zaman paylaşımlı olarak çalıştırma özelliğine müdahaledir. Bu gerekçelere dayalı olarak kesme düzeneğinin kritik bölge probleminin çözümü için kullanılması, geçerli bir yol olarak benimsenemez.

Dekker Algoritması ve Gelişim Süreci Donanım Gerektirmeyen Yazılıma Dayalı Çözümler Dekker Algoritması ve Gelişim Süreci

Dekker Algoritması Dekker algoritması kritik bölge probleminin çözümü için icat edilmiş ilk algoritmalardandır. 1964'te T. J. Dekker tarafından geliştirilmiştir. İki process için geliştirilmiş bir metottur. Yani ikiden fazla sayıda process varsa uygulanabilirliği yoktur.

Dekker Algoritması İlk versiyon İkinci versiyon Üçüncü versiyon Sıralı çalışma. Yürütme hızı alt process tarafından belirlenir. İkinci versiyon Karşılıklı dışlanmayı (mutual exclusion) garanti etmez. Üçüncü versiyon Ölümcül kilitlenme (dead lock) Dördüncü versiyon Karşılıklı nezaket (mutual courtesy) Son versiyon Yürütme hızı daha hızlı process tarafından belirlenir, karşılıklı dışlama garantisi, ölümcül kilitlenme ve karşılıklı nezaketi önleme.

Dekker Algoritması Dekker Algoritmasının Birinci Versiyonu : Sıralı Çalışma (Strict Alternation) Tek bir paylaşımlı değişken, hangi process’in kritik bölgeye girmesi gerektiğini gösterir. Process ilk olarak bu değişkeni sınayacak, şayet ‘turn’ değişkeninin değeri process’in numarasına eşitse kritik bölgesine girecek aksi taktirde bekleyecektir. Kritik bölgeden çıkılınca da ‘turn’ değişkeninin değeri diğer process’in işletimine izin verecek şekilde ayarlanacaktır. int turn=0; Mutual exclusion OK process P1 while (true) { nonCriticalSection1; while (turn! = 0) { } criticalSection1; turn = 1; } end P1; process P2 while (true) { nonCriticalSection2; while (turn!= 1) { } criticalSection2; turn = 0; } end P2; No Dead Lock OK Bu yaklaşım karşılıklı dışlamayı (mutual exclusion) sağlar, Ancak process’ler sıra ile çalışmak zorundadır.

Dekker Algoritması ‘turn’, paylaşılan global bir değişken olsun. Dekker Algoritmasının Birinci Versiyonu : Sıralı Çalışma (Strict Alternation) ‘turn’, paylaşılan global bir değişken olsun. ‘turn’ 0 iken process P1 kritik bölgesine girer, P2 bekler. P1 kritik bölgeyi terk ederken ‘turn’ değişkenini 1 yaparak P2’nin kritik bölgeye girmesine olanak tanır. P1’in tekrar kritik bölgeye girmesi P2’nin kritik bölge işlemini tamamlaması ile mümkün olur. int turn=0; process P1 while (true) { nonCriticalSection1; while (turn! = 0) { } criticalSection1; turn = 1; } end P1; process P2 while (true) { nonCriticalSection2; while (turn!= 1) { } criticalSection2; turn = 0; } end P2;

Dekker Algoritması Dekker Algoritmasının Birinci Versiyonu : Sıralı Çalışma (Strict Alternation) Process’ler farklı hızlarda çalışabilecek olmalarına rağmen ancak sıralı şekilde çalışmak zorundadır. Gereksiz yere bekleme problemine sebep vermektedir. Bekleme blok durumda gerçekleşmediğinden CPU’nun kullanılmamasına sebep olur. Bu da kaynak israfıdır. Eğer process’lerden birisi biterse diğer process en fazla bir iterasyon sonunda boş beklemede sonsuz döngüye girer.

Dekker Algoritması Dekker Algoritmasının Birinci Versiyonu : Sıralı Çalışma (Strict Alternation) Bu algoritma ile process’ler kritik kesimlerine “bir o bir bu” diye nitelenebilen değişmez bir sırada erişebilmektedirler. Bir process kritik kesiminden çıkışta erişim sırasını diğer process’e bırakmakta, diğer process kritik bölgesine girmediği sürece ilk process bir daha kritik bölgesine girme hakkı kullanamamaktadır. Bu da, bir process’in kritik kesiminin dışında olmasına karşın diğer process’lerin kritik kesimlerine girmelerini engelleyen bir durum oluşturmaktadır.

Dekker Algoritması Dekker Algoritmasının İkinci Versiyonu : int c1=1; int c2=1; Process’leri ortak kaynağa değişmez bir sırada erişmeye zorlayan bir önceki yaklaşımın aşılması amacıyla, Her iki process’e de birer değişken tahsis etmek suretiyle bu durum aşılabilir. Her process (Pi) şimdi kendi değişkenine sahiptir (Ci). Paylaşılan değişken Ci==0 Pi'nin kritik bölgesine girmek üzere olduğuna işaret ediyor. process P1 while (true) { nonCriticalSection1; while (c2!=1) { } c1=0; criticalSection1; c1=1; } end P1; process P2 while (true) { nonCriticalSection2; while (c1!=1) { } c2=0; criticalSection2; c2=1; } end P2; Mutual exclusion X

Dekker Algoritması Dekker Algoritmasının İkinci Versiyonu : Kritik bölgeye erişmek isteyen process’ler kritik kesimlerine girmeden önce bu değişkeni sınarlar. Değişken içeriğinin 0 (sıfır) bulunması durumunda, kritik kesim girişinde bekleme sürdürülür. Değişken içeriğinin 1 (bir) bulunması durumunda ise içerik sıfırlanarak kritik kesime girilir. Kritik kesim çıkışında değişken içeriği kurularak (birlenerek-1) diğer process’lerin kaynağa erişebilmesi sağlanır.

Dekker Algoritması Dekker Algoritmasının İkinci Versiyonu : 1. P1 checks c2 and finds c2==1. 2. P2 checks c1 and finds c1==1. 3. P1 sets c1 to 0. 4. P2 sets c2 to 0. 5. P1 enters its critical section. 6. P2 enters its critical section. P1 ‘while’ döngüsünde ‘c2’ değişkenini ‘1’ olarak, daha sonrada P2 ‘c1’ değişkenini ‘1’ olarak tespit ederse, her iki process de kritik kesimine girecektir. Bu yaklaşım da karşılıklı dışlama (mutual exclusion) şartını sağlamamaktadır.

Dekker Algoritması Dekker Algoritmasının Üçüncü Versiyonu : int c1=1; int c2=1; Karşılıklı dışlama şartı sağlanmıştır. Bu yaklaşımda bir proses diğer prosesin durumunu bilmeksizin durumunu set edebilir. Ancak, her iki process’in de Ci değişkenlerinin değerini ‘0’ yaptığını ve birinin ‘while’ döngüsüne girdiğini düşündüğümüzde kilitlenme meydana gelecektir. Bunun sebebi; her iki process’in de birbirlerinin Ci değişkenlerinin ‘1’ olmasını beklemesidir. process P1 while (true) { nonCriticalSection1; c1=0; while (c2!=1) { } criticalSection1; c1=1; } end P1; process P2 while (true) { nonCriticalSection2; c2=0; while (c1!=1) { } criticalSection2; c2=1; } end P2; Mutual exclusion No deadlock OK X

Dekker Algoritması Dekker Algoritmasının Üçüncü Versiyonu : Ölümcül Kilitlenme (Dead Lock) 1. P1 sets c1 to 0. 2. P2 sets c2 to 0. 3. P1 tests c2 and remains in the loop. 4. P2 tests c1 and remains in the loop. Her iki process de kritik bölge öncesi ön protokollerinde sonsuza dek kilitli.

Dekker Algoritması Dekker Algoritmasının Dördüncü Versiyonu : int c1=1; int c2=1; process P1 while (true) { nonCriticalSection1; c1=0; while (c2!=1) { c1=1;c1=0; } criticalSection1; c1=1; end P1; process P2 while (true) { nonCriticalSection2; c2=0; while (c1!=1) { c2=1;c2=0; } criticalSection2; c2=1; end P2; Process’ler, aynı anda kritik bölgelerine girmek istediklerinde, ikisinin de aynı anda girmeye çalıştıklarını farkederler. Bu yaklaşım, karşılıklı dışlama şartı sağlamaktadır. Ancak, livelock ve starvation oluşabilir. Livelock, bir tür ölümcül kilitlenme (deadlock) halidir. Mutual exclusion No livelock No starvation OK X X

Dekker Algoritması Dekker Algoritmasının Son Versiyonu : Mutual exclusion No deadlock No starvation OK OK OK int c1=1; int c2=1; int turn=1; process P1 while (true) { nonCriticalSection1; c1=0; while (c2!=1) if (turn==2){ c1=1; while (turn!=1) { } } criticalSection1; c1=1; turn=2; end P1; process P2 while (true) { nonCriticalSection2; c2=0; while (c1!=1) if (turn==1){ c2=1; while (turn!=2) { } } criticalSection2; c2=1; turn=1; end P2;

Dekker Algoritması Dekker Algoritması matematiksel yönden tam doğrudur ve karşılıklı dışlama problemini çözmüştür. Ancak algoritma oldukça karmaşıktır. Aynı zamanda bu algoritma en çok iki process’in senkronizasyonu için kullanılabilmekte, ikiden çok process için genelleştirilememektedir. Yani ikiden fazla sayıda process varsa uygulanabilirliği yoktur. Bu önemli kısıtlamadan dolayı pratikte uygulanamamıştır. Bunun yanında Peterson da kritik bölge probleme yönelik bir algoritma geliştirmiştir.

Peterson Algoritması Peterson’un çözümünün anlaşılması daha kolaydır. Peterson‘un orijinal algoritması sadece iki process ile çalışır. Fakat bu algoritma ikiden fazla process için genelleştirilebilir. boolean flag[2]={false, false}; int turn; Bu yöntemde de bir dizi oluşturulur ve her process için dizide bir eleman tutulur. Her process dizide kendisi için tutulan değişkeni 1 veya 0 yapar. Örneğin Process1 kritik bölgeye girdiğinde dizideki değişkenini 1 yapar. Process2 de diziye girememiş olur. Process1'in değişkeni sıfır olmadan Process2 kendi değişkenini 1 yapamaz. process P1 do { flag[0]=true; turn=1; while (flag[1] && turn = = 1); criticalSection1; flag[0]=false; } while (true); end P1; process P2 do { flag[1]=true; turn=0; while (flag[0] && turn = = 0); criticalSection2; flag[1]=false; } while (true); end P2; Mutual exclusion No deadlock No starvation OK OK OK

Peterson Algoritması boolean flag[2]={false, false}; int turn; Bu process kritik bölgeye girmeye hazır process P1 do { flag[0]=true; turn=1; while (flag[1] && turn = = 1); criticalSection1; flag[0]=false; } while (true); end P1; process P2 do { flag[1]=true; turn=0; while (flag[0] && turn = = 0); criticalSection2; flag[1]=false; } while (true); end P2; Diğer process kritik bölgeye girmeye hazırsa öncelik ona verilir. Sıra kendisine gelene kadar bekler Kritik kesimden çıkış bildirimi (flag[0] = false)

Peterson Algoritması Eğer turn = 0 ise, kritik bölgeye P1 girecektir. flag[ ] bitleri ise process’lerin kritik bölgeye girmeye hazır durumunu gösterir. Eğer flag[0] = true ise, P1 kritik bölgeye girmeye hazırdır. flag[0] = true VE turn = 0 olunca P1 kritik bölümüne girer. turn değişkenini iki process’te aynı anda değiştirse bile, son değer alınır ve o process kritik bölgeye girer (mutual exclusion). Kritik bölgeyi tamamlayan process kritik bölgeye giriş isteğini iptal eder ve diğer process kritik bölgeye girer (progress). Bir process kritik bölgeye bir kez girdikten sonra sırayı diğerine aktarır (bounded waiting). boolean flag[2]={false, false}; int turn; process P1 do { flag[0]=true; turn=1; while (flag[1] && turn = = 1); criticalSection1; flag[0]=false; } while (true); end P1; process P2 do { flag[1]=true; turn=0; while (flag[0] && turn = = 0); criticalSection2; flag[1]=false; } while (true); end P2;

Peterson Algoritması Peterson algoritması da doğru bir şekilde kullanılabilir fakat bu metot yoğun beklemeyi yani işlemcinin boşuna kullanılmasını gerektirir. Bir process değişken değerini değiştirip, beklemede olan diğer process’in çalışabileceği sinyalini verirken aslında kendisinin çalışamayacağını da kodlamış olur. Ayrıca yoğun olarak bekleyen process, kritik bölgede çalışan bir process’den daha öncelikli olabilir. Bu durumda zamanlayıcı (scheduler) her zaman yoğun bekleyen sürece çalışma hakkı verebilir, bu şekilde sonsuza kadar iki process de bekler. Peterson'un algoritması gibi çözümlerin modern bilgisayar mimarilerinde çalışmasının garantisi yoktur.