Bölüm 10:Aynı Anda İki Şey

Bir önceki bölümde CPU’yu process’ler arasında paylaştırdık. Timer düzenli aralıklarla bir kesme üretiyor, kernel çalışan işin bütün durumunu kaydedip başkasınınkini yüklüyor, sonra hayat kaldığı yerden devam ediyordu. Preemption’ın bütün vaadi buydu: kesilen programın kesildiğinden haberi olmaz.

O vaadin bir ince yazısı var ve orada söylemedim. Program kesildiğini fark etmez, doğru. Ama kesmenin nerede geleceğini seçen sen değilsin. Timer senin hangi satırda olduğunu bilmez, umursamaz da. Yazdığın bir satır işlemcinin gözünde tek bir iş değilse ve söz tam ortasında elinden alınırsa ne olur?

Bir borcum daha var. Öncelik tersine dönmesini anlatırken “düşük öncelikli görev paylaşılan bir kaynağın kilidini alır” deyip geçmiştim. Kilidin ne olduğunu, neden var olduğunu ve onu koyan kişinin kendi ayağına nasıl sıktığını oraya sığdırmadım. Burada ödüyorum.

Donanım tarafını ise 8. bölümde MESI protokolünü konuşurken zaten görmüştük: iki çekirdek aynı cache line’a dokunduğunda kimsenin elinde bayat bir kopya kalmıyordu. Bu bölüm o resmin üstüne yazılım tarafını koyuyor. Çünkü donanımın verdiği söz ile senin istediğin şey aynı şey değil. Donanımın sözü tek bir adres hakkındadır: aynı yere bakan iki çekirdek farklı değerler görmez. Senin üç adımının arasına kimsenin girmediğini garanti etmez — bölümün sonunda göreceğin gibi, iki farklı adrese yaptığın yazmaların karşı çekirdeğe hangi sırayla görüneceğini de garanti etmez.

Bu bölümde neyi çözüyoruz?

• Thread ile process arasındaki farkı ve bu farkın neden bütün sorunların kaynağı olduğunu netleştireceğiz.
• Paylaşılan bir sayacı artırmanın neden tek bir iş olmadığını ve arada tam olarak neyin kaybolduğunu göreceğiz.
• İki işin aynı yere aynı anda girmesini engelleyen bir çözümün hangi üç koşulu birden taşıması gerektiğini çıkaracağız.
• Kilidin donanımdan tam olarak ne istediğini, atomik komut olmadan neden kurulamadığını göstereceğiz.
• Kilitlerin kendi ürettiği iki yeni sorunu, kilitlenmeyi ve yavaşlamayı, birbirinden ayıracağız.
• Donanımın tutarlılık sözünün nerede bittiğini, yazma sıralarının neden bozulduğunu ve kilidin aslında iki iş birden yaptığını göreceğiz.

Önce Terim: Thread Nedir?

Buraya kadar “process” dedim ve 3. bölümde tanımını da verdim: çalışan bir programın kendi belleği ve kendi durumu olan canlı örneği. Bu bölümde bir terim daha gerekiyor ve aradaki fark, birazdan anlatacağım bütün sorunların kaynağı.

Bir process’in içinde birden fazla yürütme akışı olabilir. Bunların her birine thread (iş parçacığı) denir. Aynı process’in thread’leri şunları paylaşır: aynı adres alanı, aynı açık dosyalar, aynı kod. Şunlar ise her birine ayrıdır: kendi instruction pointer’ı, kendi register seti ve kendi stack’i.

Stack’in ayrı olması zorunlu, çünkü 3. bölümde gördüğün gibi fonksiyon çağrıları dönüş adreslerini stack’e koyuyor. İki akış aynı stack’i kullansaydı biri diğerinin dönüş adresinin üzerine yazardı.

Farkı tek cümleye indirgeyelim: iki process birbirinin belleğini göremez, aynı process’in iki thread ise aynı belleğe bakar. Sanal bellek, process’ler arasına donanım destekli bir duvar çeker — bunu 16. bölümde ayrıntısıyla göreceğiz. Thread’ler arasında öyle bir duvar yoktur, çünkü olmaması istenir.

İşte bu bölümün konusu o duvarın yokluğundan doğuyor. Paylaşmak ucuzdur: iki thread aynı diziye, aynı sayaca, aynı yapıya doğrudan erişir; veri kopyalamaya, mesajlaşmaya gerek kalmaz. Bedeli ise şu: ikisi aynı anda aynı yere dokunduğunda kimse onları durdurmuyor.

Kernel açısından bakıldığında scheduler’ın sıraya koyduğu şey process değil, thread’dir. Yani 9. bölümde anlattığım zaman dilimi, kesme ve context switch’in tamamı buraya olduğu gibi geçerlidir; tek fark, kesilen akışın komşusunun aynı belleğe bakıyor olması.

Bir Artırmanın Üç Adımı

Basit bir deney kuralım. İki thread var ve ortak bir sayaca bakıyorlar. İkisi de aynı işi yapıyor: sayacı bir artır, bunu bir milyon kez tekrarla. Beklenen sonuç iki milyon. Programı çalıştır ve çıktıya bak. Çoğu zaman daha az. Bazen bir tık az, bazen yüz binlerce az. Aynı program, aynı makine, her koşuda başka bir sayı.

Sebebi, o tek satırın tek bir iş olmaması. İşlemci belleğe dönüp “şunu bir artır” demez. Değeri kendi register’ına alır, orada artırır, sonra geri yazar:

mov eax, [sayac]   ; oku
add eax, 1         ; değiştir
mov [sayac], eax   ; yaz

Buna oku-değiştir-yaz (read-modify-write) denir ve arada iki tane gerçek boşluk vardır. Şimdi timer’ı tam o boşluklardan birine yerleştir. A thread’i sayacı okudu, değeri 41 buldu, register’ında 42’yi hesapladı. Tam geri yazmadan kesildi. Kernel devreye girdi, B thread’ini çalıştırdı. B aynı sayacı okuyor ve hâlâ 41 görüyor, çünkü A’nın 42’si daha kimsenin göremediği bir register’da duruyor. B 42’yi yazıp işini bitiriyor. Sıra tekrar A’ya geliyor ve A kaldığı yerden devam ediyor: elindeki 42’yi belleğe yazıyor.

İki artırma yapıldı, sayaç bir arttı. Kimse hata vermedi, kimse çökmedi. Bir sayı sessizce buharlaştı.

Bu hataya yarış durumu (race condition) denir: sonucun, işlerin hangi sırayla ilerlediğine bağlı olması. Adı yerinde, çünkü ortada gerçekten bir yarış vardır ve kimin kazandığını kimse belirlemez.

Tek talimata indirsen kurtulamazsın. x86’da belleği doğrudan artıran tek bir talimat da vardır, ama o talimat da içeride okur ve yazar; çok çekirdekli bir makinede iki çekirdek aynı anda bunu yaparsa aynı şey olur. Talimatı gerçekten bölünmez yapan şey talimatın kendisi değil, önüne konan lock ön ekidir. Yani atomiklik bedava gelen bir özellik değil, açıkça istenen bir hizmet.

En can sıkıcı tarafı ise şu: bu hata testte görünmez. Yüz koşunun doksan dokuzunda doğru sonucu alırsın, çünkü kesmenin tam o iki talimatın arasına düşmesi ihtimal işidir. Makineyi değiştirirsin, yük artar, çekirdek sayısı çoğalır ve hata bir gün üretimde ortaya çıkar. Kernel’ın kendisi bile bundan muaf değildir; yeni process’e numara dağıtan sayaç korunmazsa iki farklı process aynı kimliği alabilir.

Kritik Bölge: Girişi Tek Kapıya İndirmek

Kodun paylaşılan veriye dokunan parçasına kritik bölge (critical section) denir. Yukarıdaki üç satır bir kritik bölgedir. Kural basit görünür: bir iş kendi kritik bölgesindeyken, başka hiçbir iş kendisininkine giremez. Buna karşılıklı dışlama (mutual exclusion) denir ve aradığımız şeyin adı budur.

Ama karşılıklı dışlama tek başına yeterli bir hedef değil. Kapıyı kalıcı olarak kilitleyip anahtarı atmak da karşılıklı dışlama sağlar. Kullanılabilir bir çözümün üç koşulu birden taşıması gerekir:

• Karşılıklı dışlama. İçeride aynı anda en fazla bir iş bulunur.
• İlerleme. İçeride kimse yoksa ve girmek isteyenler varsa, kimin gireceğine karar vermek süresiz ertelenemez. Boş bir odanın önünde beklenmez.
• Sınırlı bekleme. Sıraya giren bir iş sonsuza kadar bekletilemez; başkalarının onun önüne geçme sayısının bir üst sınırı olmalıdır.

Üçüncüsü çoğu zaman atlanır ve bedeli sonra ödenir. İlk ikisini sağlayan bir çözüm, şanssız bir işi sonsuza kadar kapının önünde tutabilir.

Akla gelen ilk kaba çözüm, kritik bölgeye girmeden kesmeleri kapatmaktır. Mantıklı görünüyor: 9. bölümde preemption’ın timer kesmesiyle yapıldığını anlatmıştık, kesme gelmezse kimse seni kesemez. Üç sebeple işe yaramaz. Uzun bir kritik bölge sistemin nefesini keser; bir saat süren bir işlem boyunca makine hiçbir kesmeye cevap veremez. İkincisi, ikinci bir çekirdek zaten kendi işine devam eder ve senin kapattığın kesmeler onu hiç ilgilendirmez. Üçüncüsü de yetki meselesi: 4. bölümde user mode ile kernel mode arasına çizdiğimiz sınırın anlamı tam olarak buydu, kesmeleri kapatmak ayrıcalıklı bir iştir ve sıradan bir programın eline verilmez.

Kilit: Donanımdan İstenen Söz

Uygulama programcısının gördüğü çözümün adı kilit, yaygın adıyla mutex (mutual exclusion lock). Arayüzü iki işlemden ibarettir: kilidi al, kilidi bırak. Alan varsa diğerleri bekler.

Şimdi bunu kendin yazmayı dene. Bir bayrak tutarsın, “kilitli mi?” diye bakarsın, değilse kilitli işaretlersin. Yani önce okursun, sonra yazarsın. Tanıdık geldi mi? Bu da bir oku-değiştir-yaz dizisidir ve iki iş aynı anda “kilitli değil” görüp ikisi birden içeri girebilir. Kilidi korumak için bir kilide ihtiyacın olur ve sonsuz döngüye girersin.

Yazılım tarafında bunu kurmak imkânsız değil. Peterson’ın algoritması, iki iş için, yalnızca sıradan okuma ve yazma kullanarak üç koşulu da sağlar. Ama iki varsayıma yaslanır: iki iş olacak ve talimatlar yazdığın sırayla yürütülecek. İkincisi modern bir işlemcide doğru değildir.

Gerçek çözüm donanımdan gelir. İşlemciler, okuma ile yazma arasında kimsenin araya giremeyeceği özel talimatlar sunar. En eskisi test-and-set: bir değişkeni oku, aynı bölünmez adımda içine “dolu” yaz, sana da bulduğun eski değeri döndür. Eski değer “boş” ise kilit senindir; “dolu” ise başkasındadır.

Daha güçlüsü compare-and-swap (karşılaştır-ve-değiştir). Bu talimat üç şey alır: bir adres, orada bulmayı beklediğin değer ve yazmak istediğin yeni değer. Beklediğin değer oradaysa yenisini yazar, değilse hiçbir şeye dokunmaz. Her iki durumda da ne bulduğunu sana söyler. Koşullu olması onu çok daha kullanışlı yapar; sıradan bir sayacı atomik yapmak bile bu talimatın üstüne kurulur.

Kilidi bekleyen bir iş ne yapmalı? İki cevap var ve seçim ucuz değil. Birincisi dönerek beklemektir: spinlock kilidi alana kadar döngüde kalır, CPU’yu bırakmaz. Kritik bölge çok kısaysa bu doğru tercihtir, çünkü uyuyup uyanmanın maliyeti beklemekten fazladır. Kritik bölge uzunsa felakettir; çekirdek boşuna dönerken kilidi tutan iş belki de çalışmayı bekliyordur. İkincisi uyumaktır: kernel’a haber ver, sıraya gir, kilit bırakılınca uyandırıl. Bunun bedeli ise 9. bölümde konuştuğumuz context switch’tir. Linux’un futex’i ikisini birleştirir; çekişme yoksa iş user-space’te biter, gerçekten beklemek gerekiyorsa kernel’a inilir.

Semafor: Sayacı Olan Kilit

Kilit tek bir izin dağıtır. Peki elinde beş özdeş kaynak varsa ve aynı anda beş işin çalışmasına izin vermek istiyorsan? Dijkstra’nın 1960’larda önerdiği semafor tam olarak bunun için var: içinde bir tam sayı tutan ve iki işlemle yönetilen bir izin sayacı.

İşlemlerin klasik adları wait ve signal. wait sayacı bir azaltır; sayaç sıfırın altına düşecekse çağıran iş sıraya girer ve uyur. signal sayacı bir artırır; sırada bekleyen varsa birini uyandırır. Sayaç bire kurulursa davranışı bir kilitten farksızdır, buna ikili semafor denir. Bire kurulmazsa sayan semafor olur ve kaynak havuzu yönetir.

Kilitten önemli bir farkı vardır ve karıştırılması pahalıya patlar: semafor sahiplik taşımaz. Kilidi alan bırakmak zorundadır. Semaforu ise bir iş indirip bambaşka bir iş artırabilir. Bu onu bir dışlama aracı olmaktan çıkarıp bir haberleşme aracına dönüştürür. “Sen bitirmeden ben başlamayayım” demenin en kısa yolu, sıfıra kurulmuş bir semafordur.

Bunun klasik gösterimi üretici-tüketici problemidir. Sabit boyutlu bir tampon var. Üretici içine veri koyuyor, tüketici alıyor. Üç şeyi aynı anda garantilemen gerekiyor: tampon doluyken üretici beklemeli, boşken tüketici beklemeli ve tamponun kendi iç yapısına aynı anda iki el dokunmamalı. Üç semaforla çözülür. Biri boş yerleri sayar, biri dolu yerleri sayar, üçüncüsü de tamponu koruyan sıradan bir kilittir. Üretici önce boş yer alır, sonra kilidi alır, veriyi koyar, kilidi bırakır ve dolu sayacını artırır. Tüketici aynı şeyi ters yönde yapar.

Sıraya dikkat et, çünkü bu bölümün geri kalanı orada saklı. Üretici önce kilidi alıp sonra boş yer beklerse, tampon dolu olduğunda kilidi elinde tutarak uyur. Tüketici de veri almak için o kilide ihtiyaç duyar. İkisi de sonsuza kadar bekler.

Ölümcül Kilitlenme: Dördü Birden

Yukarıdaki tuzağın adı ölümcül kilitlenme (deadlock) ve iki kilitle en yalın hâlini kurabilirsin:

// T1                 // T2
kilitle(A);           kilitle(B);
kilitle(B);           kilitle(A);

T1, A’yı aldı ve B’yi bekliyor. T2, B’yi aldı ve A’yı bekliyor. İkisi de bekledikleri şeyi ancak diğerinin bırakmasıyla alabilir, ikisi de bırakmak için önce almak zorunda. Sistem çökmez, CPU kullanımı sıfıra iner, iki iş de sonsuza kadar orada durur.

Bunun dört koşulu vardır ve ilginç olan şu: dördü aynı anda sağlanmadan kilitlenme oluşmaz.

• Karşılıklı dışlama. Kaynak paylaşılamaz; aynı anda tek bir iş kullanabilir.
• Tut-ve-bekle. Elinde bir kaynak varken başka bir kaynak isteyebiliyorsun.
• Kesintisizlik. Bir kaynak zorla geri alınamaz; ancak tutan iş gönüllü bırakır.
• Dairesel bekleme. Bekleyenler bir halka oluşturur: her biri, bir sonrakinin elindeki kaynağı bekler.

Dördü birden gerektiğine göre birini kırmak yeter. Şimdi hangisinin kırılabileceğine bakalım, çünkü hepsi eşit derecede kırılabilir değil.

Karşılıklı dışlamayı kırmak kilidin varlık sebebini yok eder; korumak istediğin veri zaten paylaşılamadığı için oradadır. Tut-ve-bekle’yi kırmak için her işin ihtiyacı olan bütün kilitleri en baştan alması gerekir; bu, kaynak kullanımını yerlerde süründürür ve talihsiz bir işi süresiz bekletebilir. Kesintisizliği kırmak, yani kilidi zorla geri almak, yarıda kalmış bir değişikliği ortada bırakır. Geriye dairesel bekleme kalır.

Onu kırmak şaşırtıcı derecede ucuzdur: bütün kilitlere bir sıra numarası ver ve herkesin kilitleri artan numara sırasında almasını şart koş. Yukarıdaki örnekte A’ya 1, B’ye 2 dersen, T2’nin yazdığı sıra kural dışı kalır ve düzeltilir. Halka niye kurulamaz? Kurulabilmesi için zincirin bir yerinde birinin büyük numaralı bir kilidi tutarken küçük numaralı birini beklemesi gerekir. Kural bunu yasakladığı için döngü kapanamaz. Çok kilitli sistemlerde kilit sıralaması yazılı bir sözleşmedir ve ihlali derleme zamanında değil, üretimde ortaya çıkar.

Kilitlenmeyle başa çıkmanın başka yolları da var. Sistem her istekte “bu tahsis beni güvensiz bir duruma sokar mı?” diye hesaplayabilir; bankacı algoritması budur ve her işin en fazla ne kadar kaynak isteyeceğini önceden bilmeyi gerektirir. Ya da kilitlenmenin oluşmasına izin verip periyodik olarak arar, bulunca birini kurban seçip geri alırsın. Genel amaçlı işletim sistemlerinin çoğu ise üçüncü yolu seçer: görmezden gelir ve sorumluluğu programcıya bırakır. Veritabanları bu konuda daha titizdir, çünkü bir işlemi geri almanın maliyetini zaten ödemeye hazırdırlar.

Açlık ve Canlı Kilit

Bekleme her zaman kilitlenme değildir. Açlık (starvation) durumunda sistem gayet ilerler, kimse takılmaz, ama belli bir iş sırasını hiç alamaz. Sınırlı bekleme koşulunun ihlali tam olarak budur. Öncelik tersine dönmesi de bunun bir akrabasıdır; orada bekleyen iş sırasını başkasının önceliği yüzünden kaybediyordu.

Canlı kilit (livelock) daha da tuhaftır. İki iş de sürekli bir şeyler yapar, durumları sürekli değişir, ama hiçbiri ilerlemez. Koridorda karşılaşan ve ikisi de aynı yöne kaçmaya çalışan iki insan gibi. Kilitlenmeyi önlemek için yazılan “kilidi alamazsan elindekini bırak ve baştan dene” mantığı, iki iş aynı ritimde çalıştığında tam olarak buna dönüşür. Çözüm nezaket değil, rastgeleliktir: yeniden denemeden önce rastgele bir süre beklemek ritmi bozar.

Kilidin Bedeli

Kilit doğru kullanıldığında bile ücretsiz değildir ve faturanın büyük kısmı 8. bölümde anlattığımız cache mekanizmasından gelir.

Çekişme yoksa maliyet küçüktür. Kilit değişkeni zaten senin çekirdeğinin cache’indedir, atomik talimat birkaç çevrimde biter ve iş user-space’te kapanır. Çekişme başladığında tablo değişir. Kilit değişkeni bir cache line’ın içinde oturur ve o satıra yazmak isteyen her çekirdek, satırı önce kendi sahipliğine almak zorundadır. Sekiz çekirdek aynı kilidi denerken o tek satır çekirdekler arasında sürekli el değiştirir. Kritik bölge bir nanosaniye sürse bile kilidin kendisi trafiğe boğulur.

Bu, 8. bölümdeki false sharing’in yakın akrabası. Aradaki fark şu: orada paylaşım sahteydi, değişkenlerin yan yana durmasından kaynaklanıyordu. Burada paylaşım gerçek. Aynı satıra gerçekten herkes dokunmak istiyor ve çözüm hizalamayla gelmiyor.

Pratik sonuç, kilidin kapsamı üzerine düşünmeyi zorunlu kılar. Tek bir büyük kilit yazması kolaydır ve doğruluğu tartışılmaz; karşılığında programın paralel kısmını seri hâle getirir. Linux’un yıllarca taşıdığı ve sökmesi uzun süren Big Kernel Lock bunun en bilinen örneğidir. Kilidi parçalamak, örneğin her veri yapısına ayrı kilit vermek, paralelliği geri kazandırır ama iki yeni maliyet getirir: alınacak kilit sayısı artar ve kilitlenme ihtimali doğar. 6. bölümde çekirdek çoğaltmanın sınırını konuşurken andığım Amdahl yasasının tavan hesabı burada somutlaşıyor; programın seri kalan kısmı çoğu zaman tam olarak kilit tuttuğun bölgedir.

Donanımın Sözü Nerede Bitiyor?

Bölümün başında donanımın garantisinin tek bir adres hakkında olduğunu söyleyip geçmiştim. O cümlenin arkasını şimdi açıyorum, çünkü buraya kadar öğrendiğin her şeyin neden işe yaradığı orada saklı.

Birbirine benzeyen iki ayrı garanti var ve karıştırılmaları bu alanın en pahalı hatasıdır:

• Coherence (tutarlılık) tek bir adres hakkındadır: bir çekirdek x’e yazdığında diğerleri bayat bir x kopyasıyla kalmaz. MESI’nin yaptığı iş tam olarak budur.
• Consistency (sıra tutarlılığı) farklı adreslere yapılan işlemlerin hangi sırayla görüneceği hakkındadır. MESI bu konuda tek kelime etmez.

Aralarındaki uçurumu, alanın klasikleşmiş küçük testi gösteriyor. İki thread, iki değişken, dört satır:

// başlangıçta: x = 0, y = 0

// Thread 1        // Thread 2
x = 1;             y = 1;
r1 = y;            r2 = x;

Soru şu: iş bittiğinde r1 ve r2 ikisi birden 0 olabilir mi?

Kâğıt üstünde imkânsız görünüyor. Dört satırı hangi sırayla dizersen diz, ikisinden en az biri diğerinin yazmasını görmek zorunda gibi. Deneyin cevabı ise şu: evet, olabilir — ve kendi x86-64 makinende olur.

Sebebi bir kez öğrenince bir daha unutulmuyor. Bir çekirdek yazdığı değerin cache’e yerleşmesini beklemez; öyle yapsaydı her yazmada yüzlerce clock cycle boşa giderdi. Yazma önce store buffer denen küçük bir kuyruğa düşer, çekirdek yoluna devam eder, kuyruk arkadan boşalır. Kendi okumaların bu kuyruğu da tarar — yani x = 1 yazan thread x’i sorduğunda 1 görür. Ama karşı çekirdek o kuyruğu göremez. Onun için x hâlâ 0’dır. İki thread de kendi yazmasını kuyrukta bırakıp diğerinin henüz güncellenmemiş değişkenini okursa, iki sıfır birden ortaya çıkar.

Dikkat et: burada hiçbir cache line bayat değil. Coherence kusursuz çalışıyor. Bozulan şey sıra.

İkinci Sıra Bozucu: Derleyici

İşin can sıkıcı tarafı, CPU bu işe girişmeden önce bir yeniden sıralayıcının daha devrede olması. Derleyici, tek başına çalışan bir thread için sonucu değiştirmeyen her düzenlemeyi yapmakta serbesttir: satırların yerini değiştirir, bir değişkeni bellek yerine register’da tutar, döngüden değişmeyen okumayı dışarı çıkarır.

Tek thread’de bunların hiçbiri fark edilmez — zaten kural da odur. Ama “tek thread’de fark edilmez” ile “hiç fark edilmez” aynı şey değil. Derleyici senin başka bir thread’in o değişkene baktığını bilmiyorsa, onu bir kez okuyup register’da tutmayı tamamen meşru sayar ve döngün sonsuza kadar bayat bir değere bakar.

Buradan C ve C++‘ın en sert kuralı çıkıyor: senkronize edilmemiş erişimlerin en az biri yazma ise, buna data race denir ve dildeki karşılığı “tuhaf bir değer okursun” değil, tanımsız davranıştır. Derleyici, kodunda data race olmadığını varsayarak iyileştirme yapar. Varsayım bozulduğunda ortaya çıkan şey yanlış bir sayı değil, anlamını kaybetmiş bir programdır.

Buradaki en yaygın yanılgı volatile. C ve C++‘ta volatile derleyicinin okumayı silmesini engeller, ama ne atomiklik verir ne de sıra garantisi — thread senkronizasyonu için tasarlanmamıştır. (Java’da aynı kelime bambaşka ve çok daha güçlü bir anlam taşır; iki dili birbirine karıştırmak klasik bir tuzaktır.)

Kilit Aslında İki İş Birden Yapıyor

Şimdi bölümün en önemli cümlesi. Buraya kadar kilidi “aynı anda tek kişi girsin” diye anlattım. Bu doğru ama eksik. Kilit bir iş daha yapar: sırayı da onarır.

Bir kilidi almak acquire, bırakmak release anlamı taşır. Kilidi bırakan thread’in o ana kadar yaptığı bütün yazmalar, o kilidi sonra alan thread için görünür hâle gelmiş sayılır. Yani kilit yalnızca kritik bölgeyi çitle çevirmez, çitin içinde yaptığın işin dışarıya hangi anda göründüğünü de tanımlar.

Bu yüzden doğru kullanılmış bir kilitle yukarıdaki store buffer sorununu hiç yaşamazsın: kilidin kendisi, derleyiciye ve donanıma “buradan öteye taşıma” diyen bariyeri zaten içinde taşır. Aynı şey dillerin atomik tiplerinde de geçerlidir; std::atomic, Java’nın volatile’ı ya da Rust’ın Ordering parametresi tam olarak bu sıra sözleşmesini seçmene yarar. En katı seçenek olan sequential consistency, “herkes bütün işlemleri tek bir ortak sırada görsün” der; en ucuzu ve en tehlikelisi olan relaxed ise yalnızca atomikliği verir, sıra hakkında hiçbir şey söylemez.

Pratik özet üç cümle:

• Paylaşılan veriye senkronizasyonsuz dokunma; “sadece bir bayrak” diye düşündüğün değişken de buna dâhildir.
• Sıra garantisini kendin kurmaya çalışma. Kilit ya da atomik kullan; bariyeri onlar zaten taşıyor.
• Elle bellek bariyeri (fence) yazmak, kilitsiz veri yapısı yazmakla aynı ligdir. Kütüphane yazmıyorsan ihtiyacın yok.

Özet

Peki, ne öğrendik?

• Aynı process’in thread’leri adres alanını paylaşır, stack’leri ise ayrıdır. Paylaşılan bellek hem bu modelin ucuzluğu hem de bu bölümdeki sorunların tamamının kaynağıdır.
• Paylaşılan bir değeri artırmak oku-değiştir-yaz dizisidir; araya girilirse bir güncelleme sessizce kaybolur. Buna yarış durumu denir.
• Paylaşılan veriye dokunan koda kritik bölge denir ve çözümün karşılıklı dışlama, ilerleme ve sınırlı bekleme koşullarını birden sağlaması gerekir.
• Kilit yazılımla kurulamaz; test-and-set ve compare-and-swap gibi atomik donanım talimatlarına dayanır.
• Semafor sayacı olan bir izin aracıdır ve sahiplik taşımadığı için haberleşme amacıyla da kullanılır.
• Ölümcül kilitlenme dört koşulun aynı anda sağlanmasını ister; pratikte kırılan koşul dairesel beklemedir ve çaresi kilitleri sabit sırada almaktır.
• Kilitlenme olmadan da beklenebilir: açlık sırayı hiç alamamak, canlı kilit ise sürekli hareket edip hiç ilerlememektir.
• Çekişmeli bir kilit yavaşlatır, çünkü kilit değişkeninin cache line’ı çekirdekler arasında sürekli el değiştirir.
• Coherence tek bir adresin değeri hakkındadır, consistency farklı adreslerin sırası hakkında. MESI birincisini verir, ikincisini vermez.
• Yazmalar store buffer’da beklediği için, iki thread’in yazmaları karşı tarafa yazdığın sırayla görünmeyebilir. Derleyici de aynı işi bir kat daha erken yapar.
• Kilit yalnızca dışlama değil, sıra da sağlar: bırakılan kilit, o ana kadarki bütün yazmaları sonraki sahibine görünür kılar.

İki thread’in sırası bozulduğunda ne olduğunu gördük ve o sırayı bozan faillerden ikisine — store buffer’a ve derleyiciye — baktık. Geriye üçüncüsü kaldı: talimatları yazdığın sıradan bambaşka bir sırayla yürüten çekirdeğin kendisi. Peterson’ın algoritmasını anlatırken bunu söyleyip geçmiştim; o kapıyı şimdi açıyorum. Bu sefer soru “başkası ne görüyor” değil, “işlemci bunu neden yapıyor”.

Tek bir çekirdek, talimatlarını yazdığın sıradan bambaşka bir sırayla yürütüyorsa, programa sonucun sıralı olduğunu nasıl inandırıyor?