race condition

• shared memory kullanan processlerin doğru çalışmasının doğru zamanlamaya bağlı olduğu, aksi takdirde verilerin bozulduğu işlerin aksadığı durum. önlenmesine ve processlerin doğru sırada çalışmasının garanti edilmesine çalışılır.
• paylasilan bir degiskeni okumakla ilgili bir sorun olmaz da, isbu degiskenin degerini dikkatsizce degistirilirse problem cikabilir. iki farkli surecin, paylasilan bir degiskenin degerini bir artiracagini dusunelim. sureclerin nanosaniye bazinda farklarla degiskenin degerini okudugunu varsayalim (ki iki surecin de okudugu deger an itibariyle dogrudur). sonra degeri bir artirip yine nanosaniye farkiyle bellege geri yazdiklarini tasavvur edelim. ne oldu, erken yazanin yaptigi degisiklik, sonra geleninkinin altinda yok oldu gitti. deger iki artmaliydi, bir artti. ustelik bu stokastik bir durum oldugu icin, programi bir calistirirsin, dogru calisir, bir daha calistirirsin yanlis... duzeltmek icin turnike'ye benzer bir mekanizma kurmalidir, oyle ki, degerin okunmasiyla degerinin degistirilmesi icin gecen surede, diger sureclerin programin bu nahiyesinden gecmesine izin verilmez (yani olceklenebilirlige bir darbe vurulur) ama programiniz duzgun calisir. buna da kritik bolge (critical section) denir.
• iki ya da daha fazla sürecin yazdığı paylaşımlı bellek bölgelerine ya da dosyalara olan erişim zamanlarının işlemlerin sonucuna etki edebildiği durumlara denmektedir; normal koşullarda erişim zamanları, kritik sorunlara ya da avantajlara neden olmamalıdır. programcıların hayatını karartan bir durumdur. debugging filan nafiledir, çünkü herşey yolunda görünür ve buffer over flow gibi her denemede zirt pirt meydana gelmediği sadece nadiren, programdan bagimsiz cesitli surec yoneticisi kosullarinda gerceklestigi için hayat karartabilir.
  
  http://www.acikkod.org/yayingoster.php?id=27
• bir timing attack turu.
• (bkz: data race)
  (bkz: race hazard)
• (bkz: semaphore)
• debug modunda hiçbir sorun çıkarmadan aylar boyunca binlerce kere çalışan kodun release aşamasında durup dururken uygulamayı sapıttırıp yanlış sonuçlara yol açması da mümkündür. yerini bulmak da kolay olmuyor tabii son ana bırakınca... (bkz: hayatin kararması)
  
  geliştirme işlemini bir debug bir release şeklinde sürdürmeliymişiz demek ki.
  
  ekleme: 5 sene önce girdiğim bu entry'e şans eseri denk geldim. bu olay başıma geldiğimdeki stres hala aklımda.
  
  üzerinde çalıştığım proje, c++ ile geliştirilen bir adet 3d multiplayer third person shooter bitirme projesiydi. client-server mimarisine sahip bu yapıda, oyuncular kendi haritalarını yaratıp, bu haritalarda arkadaşlarıyla oynayabiliyorlardı. oyun odası yaratan client, yaratım aşamasında, kendi yarattığı yeni haritayı server'a upload ediyor ve tüm oyuncular odaya girdikten sonra verilen start komutuyla birlikte diğer client'lar server'dan harita dosyasını asenkron olarak indiriyorlardı. ardından da harita ve resource'lar yüklenip oyun başlıyordu.
  
  entersan bir şekilde, 100 kere test edilip çalıştığı görülen bu son aşama, release build aldıktan sonra, projenin sunumundan birkaç gün önce, takım halinde test ederken patır patır segmentation fault bırakmaya başladı. sadece release build ile reproduce edilebildiği için de debug etmesi çok zordu.
  
  ertesi gün sabahtan akşama kadar ilgili kısmı gözden geçirip, problemin asenkron olarak yüklenen haritadan kaynaklanığını farketmiştim. dosya indirildikten sonra, network thread'inden cağrılan callback methodu, graphics thread'inin elleştiği bir resource'a müdahale ederken race condition oluşturuyordu (ya da onun gibi birşey). problemin tespitinden sonra, function pointer'larını bir queue'ya atıp, her şeyi sırasıyla graphics thread'inde execute eden bir scheduler yazdığımı hatırlıyorum.
  
  olayın çözüldüğünü gördüğümde, sağ gözümden bir damla yaş gelmişti...
  
  patlamanın neden sadece release build'de olduğuna değinecek olursak; debug kodu release'e göre çok daha yavaş olduğu için, graphics thread daha render aşamasına geçemeden dosya serverdan indiriliyor, gerekli kaynaklar yükleniyor ve graphics kısmı render'a sorunsuz bir şekilde başlıyordu. release'de ise, dosya, render başladıktan sonra indirilmiş oluyor, kaynakları yükleyeyim derken de işi eline yüzüne bulaştırıyordu.
• iki birimin bir kaynağı değiştirmek için yarışmasından kaynaklanan problemli durum ^*
• murphy yasaları ile yakından ilgilidir
  (bkz: if something can go wrong, it goes)
• teknik terimler olmadan anlatmak gerekirse;
  
  banka hesabınızda 100 dolar var diyelim. kullanıcı hesabına iki farklı oturum açıyor. atm, mobil app, web app neyse artık. kullanıcı bu hesabından aynı anda 100 dolarlık işlem yaparak para çekti diyelim. iki işlemde aynı anda tetiklendiği için iki tarafta 100 dolara sahip olabilir. aynı zamanda iki tarafında hesapları 0 dolar olarak güncellenebilir. kullanıcı toplamda 200 dolar çekmiş oldu ve hesabında 0 doları var. işte buna race condition deniliyor.