Bolum 06

Bölüm 6: Senkronizasyon
Operating System Concepts – 8th Edition, Silberschatz, Galvin and Gagne ©2009
Bölüm 6: Senkronizasyon
 Temel Kavramlar
 Kritik Alan Problemi (The Critical-Section Problem)
 Peterson’un Çözümü
 Senkronizasyon Donanımı (Synchronization Hardware)
 Semaforlar (Semaphores)
 Klasik Senkronizasyon Problemleri
 Monitörler (Monitors)
 Senkronizasyon Örnekleri
 Atomik işlemler (Atomic Transactions)
Operating System Concepts – 8th Edition 6.2 Silberschatz, Galvin and Gagne ©2009
Temel Kavramlar
 Paylaşılan veriye koşutzamanlı erişim veri üzerinde tutarsızlıklara sebep

olabilir
 Veri tutarlılığını korumak için birlikte çalışan süreçlerin düzenli
çalıştırılmasını sağlayacak mekanizmalara ihtiyaç vardır
 Örneğin, bütün tamponları (buffer) dolduran tüketici-üretici problemine
(consumer-producer problem) bir çözüm bulmaya çalışalım:
 Bunu dolu tamponların sayısını tutan bir tamsayı sayaç ile
yapabiliriz.
 Başlangıçta sayaç 0'a eşitlenir,
 Üretici yeni bir tampon yarattığı zaman sayaç arttırılır, ve
 Tüketici tamponu kullandıktan sonra da azaltılır.
Üretici (Producer)
while (true) {
/* bir parça (item) üret ve nextProduced'ün içine koy */

while (count == BUFFER_SIZE)
; // Hiçbir şey yapma
buffer [in] = nextProduced;
in = (in + 1) % BUFFER_SIZE;
count++;
}
Tüketici (Consumer)
while (true) {
while (count == 0)
; // Hiçbir şey yapma
nextConsumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
count--;
/* nextConsumed'deki parçayı tüket

}
Yarış Şartı (Race Condition)
Birden fazla sürecin aynı veriye koşutzamanlı olarak erişmek ve
değişiklik yapmak istemesi ve işletimin sonucunun süreçlerin erişim
sıralarına göre değişmesi durumuna yarış şartı adı verilir
 count++ aşağıdaki gibi uygulanabilir
register1 = count
register1 = register1 + 1
count = register1 register1 ve register2'nin
aynı fiziksel kayıtçı olabile-
 count-- aşağıdaki gibi uygulanabilir
ğini düşünürsek sorun çıkar
register2 = count
register2 = register2 - 1
count = register2
 Başlangıçta “count = 5” değerine sahip sistemin çalışması:
S0: üretici çalışır register1 = count {register1 = 5}
S1: üretici çalışır register1 = register1 + 1 {register1 = 6}
S2: tüketici çalışır register2 = count {register2 = 5}
S3: tüketici çalışır register2 = register2 - 1 {register2 = 4}
S4: üretici çalışır count = register1 {count = 6 }
S5: tüketici çalışır count = register2 {count = 4}
Kritik Alan (Critical Section) Problemi
 Her sürecin kritik alan adı verilen bir kod alanı vardır ve bu alandayken
süreç ortak değişkenleri değiştiriyor, bir dosyaya yazıyor, bir tabloyu
değiştiriyor, vb. işlemler yapıyor olabilir.
 Önemli olan bir sürecin kritik alanı içerisindeyken diğer bir süreç
tarafından kesilmesine izin verilmemesidir.
 Bu da birden fazla sürecin aynı anda kritik alanlarında bulunmasına izin
vermemek ile gerçekleştirilebilir.
 Kritik alan problemi süreçlerin birlikte çalışırken kullanabilecekleri bir
protokol geliştirmektir:
 Her süreç kritik alana girmek için izin istemelidir. İzin isteme için
gerekli kod parçasına, giriş kısmı (entry section) adı verilir
 Kritik alanın bir de çıkış kısmı (exit section) bulunur.
 Geri kalan kod ise kalan kısımdır (remainder section)
Kritik Alan (Critical Section) Problemi
do {
Giriş Kısmı
Kritik Alan
Çıkış Kısmı
Kalan Kısım
} while (TRUE)
Pi sürecinin genel yapısı
Kritik Alan (Critical Section) Problemine Çözüm
Kritik alan problemine bir çözüm bulmak için aşağıdaki üç gereksinimin

karşılanması gerekir:
1. Karşılıklı Dışlama (Mutual Exclusion) – Eğer süreç Pi kritik alanında

çalışıyorsa, başka hiçbir süreç kritik alanında çalıştırılamaz
2. İlerleme (Progress) – Eğer hiçbir süreç kritik alanda çalıştırılmıyorsa ve
bazı süreçler kritik alana girmeyi talep ediyorlarsa, sadece kalan kısımlarını
işletmeyen süreçler arasından bir sonra kritik alanına girmesi gerekenin
seçimi yapılır ve bu seçim işlemi belirsiz bir süre için ertelenemez
3. Bekleme Limiti (Bounded Waiting) - Bir süreç kritik alanına girme talebi
yaptıktan sonra; bu süreç kritik alanına girmeden önce diğer süreçlerin kritik
alanlarına girme sayısında bir limit olmalıdır.
 Her sürecin sıfırdan farklı bir hızda çalıştığı kabul edilir

 N sürecin göreceli hızları ile ilgili bir varsayım yoktur
Peterson’un Çözümü (Yazılım Çözümü)
 İki süreç çözümü
 LOAD ve STORE komutlarının atomik olduğu varsayılır; yani
bunlar kesilemez.
 Bu iki süreç iki değişkeni paylaşırlar:

int turn;
 Boolean flag[2]
 turn değişkeni hangi sürecin kritik alanına girme sırası olduğunu
beliritir. turn == i ise Pi ‘nin kritik alana girmesine izin verilir.
 flag dizisi ise bir sürecin kritik alana girmeye hazır olduğunu
belirtmek için kullanılır. flag[i] == true  Pi sürecinin kritik alana
girmeye hazır olduğunu belirtir!
Peterson'un Çözümünde Pi Süreci için Algoritma
do {
flag[i] = TRUE;
turn = j;
while (flag[j] && turn == j);
Kritik alan
flag[i] = FALSE;
Kalan alan
} while (TRUE);
Senkronizasyon Donanımı
do {
Kiliti koy
Kritik alan
Kilidi kaldır
Kalan alan
} while (TRUE);
Kritik-Alan Problemine Kilitleri (Lock) Kullanan Bir Çözüm
Senkronizasyon Donanımı
 Birçok sistemde kritik alan kodu için donanım desteği sunmaktadır
 Tek işlemcili sistemlerde paylaşılan bir değişken değiştirilirken
kesmeler devre dışı bırakılabilirler
 Şu anda çalışan kod kesilmeden çalışmaya devam eder
 Çok işlemcili sistemlerde genellikle çok verimsizdir
 Bu şekildeki işletim sistemleri genellikle ölçeklenebilir
değildir
 Modern makinelerde özel atomik donanım komutları sunmaktadır
 Atomik = kesmesiz (non-interruptable)
 Ya bellek kelimesini test eder ve değeri değiştirir (TestAndSet)
 Ya da iki bellek kelimesinin içeriklerini değiş tokuş eder (Swap)
TestAndSet() Komutu
 Tanım:
boolean TestAndSet (boolean *target)

{
boolean rv = *target;
*target = TRUE;
return rv:
}
TestAndSet()'i Kullanarak Karşılıklı
Dışlama Sunan Bir Çözüm
 Paylaşılan boolean değişken lock, ilk değeri false.
 Çözüm:
do {
while ( TestAndSet (&lock ))
; // hiçbir şey yapma
// Kritik alan
lock = FALSE;
// Kalan alan
} while (TRUE);
Swap Komutu
 Tanım:
void Swap (boolean *a, boolean *b)

{
boolean temp = *a;
*a = *b;
*b = temp:
}
Swap'i Kullanan Çözüm
 Paylaşılan Boolean değişkeni lock, ilk değeri FALSE;
 Her sürecin bir Boolean değişken anahtarı mevcuttur
 Çözüm:
do {
key = TRUE;
while ( key == TRUE)
Swap (&lock, &key );
// Kritik alan
lock = FALSE;
// Kalan alan
} while (TRUE);
TestAndSet() Kullanan Bekleme Limitli Karşılıklı
Dışlama
Normalde TestAndSet() ve Swap() karşılıklı dışlamayı sağlar ancak sınırlı beklemeyi
sağlamaz. Aşağıdaki çözüm tüm kritik alan gereksinimlerini karşılar:
do {
waiting[i] = TRUE;
key = TRUE; Başlangıçta;
boolean waiting[n]=false;
while (waiting[i] && key)
boolean lock=false;
key = TestAndSet(&lock);
waiting[i] = FALSE; Pi sadece waiting[i]==false
// Kritik alan veya key== false olduğu
j = (i + 1) % n; durumlarda kritik alanına
girebilir.
while ((j != i) && !waiting[j])
key sadece TestAndSet
j = (j + 1) % n;
çalıştığı zaman false olabilir.
if (j == i)
lock = FALSE;
else
waiting[j] = FALSE;
// Kalan alan
} while (TRUE);
Semafor (Semaphore)
 Meşgul beklemeye (busy waiting) ihtiyaç duymayan bir senkronizasyon aracıdır
 Semafor S – integer değişken
 S'i değiştiren iki standart operasyon vardır: wait() ve signal()
 P() ve V() olarak adlandırılırlar
 Daha az karmaşıktır
 Yanlızca iki bölünemeyen (atomik) operasyon tarafından erişilebilir
 wait (S) {
while (S <= 0)
; // no-op
S--;
}
 signal (S) {
S++;
}
Genel Senkronizasyon Aracı Olarak Semafor
 Counting (Sayan) semafor – sınırsız bir alanda kullanılabilen integer değer

 Binary semafor – sadece 0 ve 1 değerlerini alabilen integer değer; daha kolay
uygulanabilir
 mutex kilitleri (mutex locks) olarak da bilinirler
 S sayan semaforunu ikili (binary) semafor olarak uygulayabilir
 Karşılıklı dışlama oluşturur
Semaphore mutex; // ilk değeri 1
do {
wait (mutex);
// Kritik alan
signal (mutex);
// Kalan alan
} while (TRUE);
Semafor Uygulaması
 Sayan (counting) semaforlar belirli sayıdaki kaynağa erişimi kontrol etmek
için de kullanılabilir:
 Semafor mevcut kaynak sayısına ayarlanır
 Bir kaynak kullanmak isteyen tüm süreçler bir wait() operasyonu (sayıyı
bir düşürür) gerçekleştirir.
 Süreç kaynağı serbest bırakırken ise signal() operasyonu (sayıyı bir
arttırmak) gerçekleştirir.
 Semaforun sayısı 0’a ulaşırsa tüm kaynaklar kullanılmıştır ve kaynak
kullanmayı bekleyen tüm süreçler sayı 0’dan büyük oluncaya kadar
bloklanmalıdır.
Semafor Uygulaması
 Semafor uygulaması iki sürecin aynı semaforda aynı zamanda wait ()
ve signal () 'i çalıştırmamasını garanti etmelidir
 Uygulama wait ve signal kodunun kritik alana yerleştirildiği bir kritik
alan problemine dönüşmüştür.
 Kritik alan uygulamasında meşgul bekleme (busy waiting) yer
alabilir
 Bir süreç kritik alanında iken diğer bir süreç kendi kritik alanına
girmek isterse sürekli olarak giriş kodunda (entry code)
dönmelidir.
 Meşgul bekleme tek CPU'lu sistemlerde problem olabilir.
 Meşgul bekleme diğer süreçler verimli bir şekilde kullanabilecekken
CPU döngülerinin harcanmasına yol açar.
 Uygulamaların çoğu zamanını kritik alanlarında geçirdiği düşünülürse
bu iyi bir çözüm değildir.
Meşgul Beklemesiz Semafor Uygulaması
 Her bir semaforla bir bekleme kuyruğu ilişkilendirilmiştir.

Bekleme kuyruğundaki her giriş iki veri barındırır:
 integer tipinde bir değer (value)
 listedeki bir sonraki kaydı gösteren işaretçi
 İki işlem vardır:

 Blokla (block) – süreci semaforun bekleme kuyruğuna
uygun bekleme kuyruğuna yerleştirir ve durumunu bekleme
durumuna
 Uyandır (wakeup) – bekleme kuyruğundaki süreçlerden bir
tanesini silip, hazır kuyruğuna yerleştirme
Meşgul Beklemesiz Semafor Uygulaması
 C dilinde semafor uygulaması
typedef struct {
int value;
struct process *list;
} semaphore;
 Wait uygulaması:
wait(semaphore *S) {
S->value--;
if (S->value < 0) {
add this process to S->list;
block();
}
}
 Signal uygulaması:
signal(semaphore *S) {
S->value++;
if (S->value <= 0) {
remove a process P from S->list;
wakeup(P);
}
} – 8th Edition
Operating System Concepts 6.24 Silberschatz, Galvin and Gagne ©2009
Kilitlenme (Deadlock) ve Açlık (Starvation)
 Kilitlenme (Deadlock) – iki ya da daha fazla sürecin yalnızca aralarından biri
tarafından oluşturulabilecek bir olayı belirsiz bir süre için beklemesidir.
 S ve Q başlangıç değerleri 1 olan iki semafor olsun
P0 P1
wait (S); wait (Q);
wait (Q); wait (S);
. .
. .
. .
signal (S); signal (Q);
signal (Q); signal (S);
 Açlık (Starvation) – belirsiz süre için bloklanma. Bir süreç bekletildiği
semafor kuyruğundan hiçbir zaman kaldırılamaz.
 Önceliklerin tersine çevrilmesi (Priority Inversion) - Yüksek öncelikli bir
süreç kilide ihtiyaç duyarken düşük öncelikli süreçlerin kilidi tuttuğu durumda
ortaya çıkan iş planlaması problemidir
Klasik Senkronizasyon Problemleri
 Sınırlı-Tampon Problemi (Bounded-Buffer Problem)
 Okuyucular ve Yazıcılar Problemi (Readers and Writers Problem)
 Yemek yiyen-Filozoflar Problemi (Dining-Philosophers Problem)
Sınırlı Tampon (Bounded-Buffer) Problemi
 Herbiri tek bir madde tutabilen N adet tampon (buffer)

 Semafor mutex (tampon havuzuna erişimler için karşılıklı dışlama
sağlar)  başlangıç değeri 1
 Semafor full (dolu tamponların sayısını tutar)  başlangıç değeri 0
 Semafor empty (boş tamponların sayısını tutar)  başlangıç değeri N
Sınırlı Tampon (Bounded-Buffer) Problemi
 Üretici (producer) sürecin yapısı  Tüketici (consumer) sürecin yapısı
do { do {
// produce an item in nextp wait (full);
wait (empty); wait (mutex);
wait (mutex); // remove an item from buffer to nextc
// add the item to the buffer signal (mutex);

signal (empty);
signal (mutex); // consume the item in nextc
signal (full); } while (TRUE);
} while (TRUE);
Okuyucular-Yazıcılar (Readers-Writers)
Problemi
 Bir veri kümesi koşutzamanlı süreçler arasında paylaşılır
 Okuyucular (Readers) – veri kümesini sadece okurlar; herhangi bir
değişiklik yapmazlar
 Yazıcılar (Writers) – hem okuyup hem de yazabilirler
 Problem 1– Bir yazıcının başlangıçta paylaşılan nesneye izni yoksa

birçok okuyucunun aynı anda okumasına izin verilebilir. (Yazıcılarda
açlığa sebep olabilir)
 Problem 2- Bir yazıcı hazırsa, yazmayı en kısa sürede
gerçekleştirebilmelidir. Yani bir yazıcı nesneye erişim için bekliyorsa,
hiçbir yeni okuyucu okumaya başlayamaz. (Okuyucularda açlığa sebep
olabilir)
 Paylaşılan Veri
 Veri kümesi (Data set)
 Semafor mutex  başlangıç değeri 1
 Semafor wrt  başlangıç değeri 1
 int readcount  başlangıç değeri 0
Problemi
 Yazıcı (writer) sürecin yapısı
do {
wait (wrt) ;
// writing is performed
signal (wrt) ;
} while (TRUE);
Problemi
 Okuyucu (reader) sürecin yapısı
do {
wait (mutex) ;
readcount ++ ;
if (readcount == 1)
wait (wrt) ;
signal (mutex)
// reading is performed
wait (mutex) ;
readcount - - ;
if (readcount == 0)
signal (wrt) ;
signal (mutex) ;
} while (TRUE);
Yemek yiyen Filozoflar
(Dining-Philosophers) Problemi
 Paylaşılan veri
 Bir tencere pilav (veri kümesi)
 Semafor chopstick [5]  başlangıç değeri 1
 Filozof i 'nin yapısı:
do {
wait ( chopstick[i] );
wait ( chopStick[ (i + 1) % 5] );
// eat
signal ( chopstick[i] );
signal (chopstick[ (i + 1) % 5] );
// think
} while (TRUE);
ÇÖZÜMLER
 En fazla dört filozofun aynı anda masada oturmasına izin ver.
 Bir filozofun sadece her iki tarafındaki çubuklar uygunsa çubuk almasına
izin ver.
 Tek sayılı bir filozofun ilk olarak solundaki sonra sağındaki çubuğu
almasına, çift sayılı filozofun ise önce sağ sonra solundaki çubuğu almasına
izin ver.
Semaforlarla İlgili Problemler
 Semafor işlemlerinin doğru kullanımı (mutex başlangıçta 1

olarak ayarlanmış ve paylaşılmış):
 signal (mutex) …. wait (mutex) – Birden çok süreç aynı

anda kritik alanda bulunabilir. Bu da karşılıklı dışlama
gereksinimine karşı olur.
 wait (mutex) … wait (mutex) – bir süreç signal(mutex) ile

wait(mutex)’in sırasını değiştirirse, bu durumda kilitlenme
oluşur.
 wait (mutex)'i veya signal (mutex)'i (veya ikisini birden)

atlamak – Bu durumda karşılıklı dışlama veya kilitlenme
oluşabilir.
Monitörler (Monitors)
 Süreç senkronizasyonu için güvenilir ve etkili bir mekanizma sağlayan
üst seviye bir soyutlamadır
 Monitör içerisinde aynı anda sadece tek bir süreç aktif olabilir
monitor monitor-name
{
// shared variable declarations
procedure P1 (…) { …. }
…
procedure Pn (…) {……}
Initialization code ( ….) { … }

…
}
}
Monitör'ün Şematik Görünümü
Giriş kuyruğu
paylaşılan veri
işlemler
Başlangıç
kodu
Durum Değişkenleri (Condition Variables)
 condition x, y;
 Bir durum değişkeninin iki işlemi vardır:

 x.wait () – bu işlemi uyandıran süreç diğer bir süreç tarafından
uyandırılıncaya kadar durdurulur.
 x.signal () – x.wait () tarafından durdurulan süreçlerden (eğer varsa)
bir tanesi devam ettirilir. Eğer durdurulmuş süreç yoksa signal()
işleminin bir etkisi olmaz
Durum Değişkenleri ile Monitör
Giriş kuyruğu
paylaşılan veri
x,y durumlarıyla
ilişkilendirilen kuyruklar
işlemler
Başlangıç
kodu
Yemek-yiyen Filozoflara
Monitör Kullanılarak Çözüm
monitor DP
{
enum { THINKING; HUNGRY, EATING} state [5] ; void test (int i) {
condition self [5]; if ( (state[(i + 4) % 5] != EATING) &&
(state[i] == HUNGRY) &&
void pickup (int i) { (state[(i + 1) % 5] != EATING) ) {
state[i] = HUNGRY; state[i] = EATING ;
test(i); self[i].signal () ;
if (state[i] != EATING) self [i].wait; }
} }
void putdown (int i) { initialization_code() {

state[i] = THINKING; for (int i = 0; i < 5; i++)
// test left and right neighbors state[i] = THINKING;
test((i + 4) % 5); }
test((i + 1) % 5); }
}
Yemek-yiyen Filozoflara
Monitör Kullanılarak Çözüm
 Her filozof pickup() ve putdown() işlemlerini aşağıdaki sırayla uyandırır:
DiningPhilosophers.pickup (i);
EAT
DiningPhilosophers.putdown (i);
Semafor Kullanılarak Monitör Uygulaması
 Değişkenler
semaphore mutex; // ( başlangıç değeri = 1)
semaphore next; // ( başlangıç değeri = 0)
int next-count = 0;
 Her prosedür F aşağıdakilerle değiştirilir (signal’i çalıştıran bir süreç devam

ettirilen süreçler bitinceye veya wait’i çalıştırıncaya kadar beklemelidir. Bu
yüzden next adında bir semafor (başlangıçta 0) kullanılır. Next_count ise next
tarafından durudurulan süreçlerin sayısını tutar.)
wait(mutex);
…
body of F;
…
if (next_count > 0)
signal(next)
else
signal(mutex);
 Monitör içerisinde karşılıklı dışlama (Mutual exclusion) sağlanmıştır.
Semafor Kullanılarak Monitör Uygulaması
 Her x durum değişkeni için:
semaphore x_sem; // (initially = 0)

int x-count = 0;
 x.wait işlemi:  x.signal işlemi aşağıdaki gibi

uygulanabilir:
x-count++;
if (next_count > 0) if (x-count > 0) {
signal(next); next_count++;
else signal(x_sem);
signal(mutex); wait(next);
wait(x_sem); next_count--;
x-count--; }
Tek bir Kaynağı Paylaştırmak İçin Monitör
 Birden çok süreç x durum değişkeni ve x.signal() kullanılarak durdurulduysa
hangi sürecin bir sonra devam ettirileceğine karar verilmesi gerekir. En basit
çözüm FCFS kullanımıdır.
 Ancak bir çok durum için bu çözüm uygun değildir.
 Bu sebeple x.wait(c); biçiminde bir şartlı-bekleme yapısı kullanılabilir.
 "c" değeri wait() işlemi işletildiğinde değerlendirilen bir tamsayı ifadedir.
 "c" değerine öncelik numarası (priority number) adı verilir ve x.signal()
çalıştırıldığında en küçük c değerine sahip süreç işletilir.
Tek bir Kaynağı Paylaştırmak İçin Monitör
monitor ResourceAllocator // En kısa kullanım süresine sahip sürece tahsis eder
{
boolean busy;
condition x;
void acquire(int time) { // Her süreç kaynağı max. ne kadar kullanacağını belirtir
if (busy) Problemler:
x.wait(time); • Bir süreç bir kaynağa önceden
busy = TRUE; erişim izni almadan erişebilir
} • Bir süreç kaynağa erişim
sağladıktan sonra onu serbest
void release() {
bırakmayabilir
busy = FALSE; • Bir süreç hiç istek yapmadığı bir
x.signal(); kaynağı serbest bırakmaya
} çalışabilir
initialization code() { • Bir süreç aynı kaynağa ikinci kez
busy = FALSE; istek yapabilir (birinciyi serbest
} bırakmadan)
}
 Her süreç bir kaynağa erişim istediğinde aşağıdaki süreci işletir:
R.acquire(t); // Bir Kaynak Paylaşımı (ResourceAllocator) örneği

…
kaynağa erişim;
….
R.release();
Senkronizasyon Örnekleri
 Solaris
 Windows XP
 Linux
 Pthreads
Solaris Senkronizasyonu
 Çoklu görev (multitasking), çoklu iş parçacığı (multithreading) (gerçek
zamanlı iş parçacıkları dahil) ve çoklu işlemeyi (multiprocessing)
destekleyen çok çeşitli kilitler uygulanmaktadır.
 Veriyi kısa kod segmentlerinden koruma sırasında verimlilik için Adaptif
karşılıklı dışlama (adaptive mutexes) (her kritik veriye erişimi koruyan
mutex) kullanılmaktadır
 Kodun daha uzun parçaları veriye erişim gereği duyduğunda Durum
değişkenleri (condition variables) ve okuyucular-yazıcılar (readers-writers)
kilitleri (lock) kullanılmaktadır
 Adaptif karşılıklı dışlama (adaptive mutex) veya okuyucu-yazıcı kilidi almak
isteyen işparçacığı listesini düzenlemek için turnikeler (turnstiles)
kullanılmaktadır
Windows XP Senkronizasyonu
 Tek işlemcili sistemlerde global kaynaklara erişimi korumak için kesme
maskeleri (interrupt masks) kullanılır
 Çok işlemcili sistemlerde dönen kilitler (spinlocks) (kilit beklerken süreç
dönmeye devam eder) kullanılır
 Mutex veya semafor gibi davranabilecek işlemci zamanlayıcısı (dispatcher
objects) kullanılır.
 İşlemci zamanlayıcılar (Dispatcher objects) ayrıca olayları (events)
oluştururlar
 Bir olay çoğunlukla bir durum değişkeni gibi davranır
Linux Senkronizasyonu
 Linux:
 Kernel Version 2.6'dan önce, kısa kritik alanları işletmek için kesmeler
devre dışı bırakılır, kesmeyen bir yapı mevcuttur.
 Version 2.6 ve sonrası, tamamen kesendir (fully preemptive), çekirdek
görevleri işlenirken kesilebilir.
 Linux'de:
 Semaforlar ve
 Döner kilitler (spin locks) kullanılmaktadır
Pthreads Senkronizasyonu
 Pthreads API'si İşletim Sistemi bağımsızdır

 Pthreads'de:
 Karşılıklı dışlama kilitleri (mutex locks)
 Durum değişkenleri (condition variables) kullanılmaktadır
 Bir uygulamadan diğerine taşınamayan genişletmeler arasında:

 Okuma-yazma kilitleri (read-write locks) ve
 Döner kilitler (spin locks) bulunmaktadır.
Bölüm 6 Sonu
Operating System Concepts – 8th Edition, Silberschatz, Galvin and Gagne ©2009

Bolum 06

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bolum 06

Uploaded by

Copyright:

Available Formats

Bölüm 6: Senkronizasyon

 Paylaşılan veriye koşutzamanlı erişim veri üzerinde tutarsızlıklara sebep

/* bir parça (item) üret ve nextProduced'ün içine koy */

/* nextConsumed'deki parçayı tüket

Pi sürecinin genel yapısı

Kritik alan problemine bir çözüm bulmak için aşağıdaki üç gereksinimin

1. Karşılıklı Dışlama (Mutual Exclusion) – Eğer süreç Pi kritik alanında

 Her sürecin sıfırdan farklı bir hızda çalıştığı kabul edilir

Kritik-Alan Problemine Kilitleri (Lock) Kullanan Bir Çözüm

boolean TestAndSet (boolean *target)

void Swap (boolean *a, boolean *b)

 Counting (Sayan) semafor – sınırsız bir alanda kullanılabilen integer değer

 Her bir semaforla bir bekleme kuyruğu ilişkilendirilmiştir.

 İki işlem vardır:

 Herbiri tek bir madde tutabilen N adet tampon (buffer)

// add the item to the buffer signal (mutex);

 Problem 1– Bir yazıcının başlangıçta paylaşılan nesneye izni yoksa

 Yazıcı (writer) sürecin yapısı

 Semafor işlemlerinin doğru kullanımı (mutex başlangıçta 1

 signal (mutex) …. wait (mutex) – Birden çok süreç aynı

 wait (mutex) … wait (mutex) – bir süreç signal(mutex) ile

 wait (mutex)'i veya signal (mutex)'i (veya ikisini birden)

procedure Pn (…) {……}

Initialization code ( ….) { … }

 Bir durum değişkeninin iki işlemi vardır:

void putdown (int i) { initialization_code() {

 Her filozof pickup() ve putdown() işlemlerini aşağıdaki sırayla uyandırır:

 Her prosedür F aşağıdakilerle değiştirilir (signal’i çalıştıran bir süreç devam

 Monitör içerisinde karşılıklı dışlama (Mutual exclusion) sağlanmıştır.

semaphore x_sem; // (initially = 0)

 x.wait işlemi:  x.signal işlemi aşağıdaki gibi

R.acquire(t); // Bir Kaynak Paylaşımı (ResourceAllocator) örneği

 Pthreads API'si İşletim Sistemi bağımsızdır

 Bir uygulamadan diğerine taşınamayan genişletmeler arasında:

You might also like

void Swap (boolean a, boolean b)