asenkron programlama

• i/o tabanlı (disk, ağ vs) işlemleri yaparken tek bir thread'in o işlemin sonucunu beklemekle uğraşmadan başka işler yapmasını sağlayan programlama modelidir.
  
  paralel programlamadan farklıdır. paralel programlama i/o mi/o ayırdetmeden her şeyi paralel çalıştırmaya çalışır. bu yüzden de paralel yapılacak işler için fazladan thread gerekir. işlemcide thread sayısına yetecek kadar çekirdek yoksa bu sefer aynı çekirdek birden fazla thread arasında geçiş yapmak zorunda kalır performansı olumsuz etkiler.
  
  asenkron programlama ise i/o'nun en güzel özelliği olan "aygıtın zaten o sırada işi kendi başlına yapması" mantığından istifade eder. mesela siz diskten bişey okuyacaksınız, bir kere diske "abi şuraları bana oku" dersiniz sonra disk ilgili içeriği dma üzerinden hafızaya kendisi taşır, işi bitince sana bir interrupt yollar. ağdan bir şey okumak da aynı şekilde. ethernet kartı tcp bağlantısını kurar buffer'ları verdiğin yerlere yerleştirir, tcp stack gelen interrupt'ları değerlendirir o kadar.
  
  yani en çok zaman harcanan kısım olan ağdan ya da diskten bir şeyler okuyup yazma esnasında aslında bir cpu'ya ihtiyaç neredeyse hiç yoktur. asenkron programlama da bundan istifade eder ve der ki "abi sen onu oku, bittiğinde benim kodun kalanını çalıştırırsın o arada benim bu thread'e ihtiyacım yok" mesajını verir. alt tarafta da işletim sistemi başka işlemleri aynı thread'i kullanarak çalıştırabilme şansı elde eder.
  
  böylece sizin ağdan 10 tane isteği aynı anda yollayıp sonuçlarını aynı anda çekmek için 10 tane thread'e ihtiyacınız olmaz. tek bir thread bütün istekleri tcp stack'e iletir, tcp stack paketleri yollar, sonuçları gelene kadar beklemek gereken kısımda sizin thread'inizi başka işler çalıştırmak için kullanır.
  
  özellikle sunucu tarafındaki yazılımlarda veritabanı erişimi ya disk ya da ağ üzerinden transfer gerektirdiğinden web sunucularındaki performansa katkısı harikuladedir. tek thread'li web server bile yaparsın o derece.
  
  modern işletim sistemlerinin tamamı bu programlama modelini destekler ama her çağrı için yeni callback function belirlemek gibi hammaliyesi olduğundan külfetlidir. c# 5.0 ve javascript'teki promises gibi yeni standartlar asenkron programlayı kolaylaştıran yapılar sunarlar.
  
  (bkz: asenkron i/o)
• ozellikle web backend'lerinin gittigi noktadir. zira buyuk siteler uzun suredir farkindalar ki blocking islemler web server'lardaki worker thread'leri uzun sure blokluyorlar ve kullaniciya istedigi cevap gidene kadar cpu'nun agzina siciliyor, oysa ki blocking islemler arasinda thread'ler pause edilip kenara koyulabilirler.
  
  is bu sebepten oturu node.js gibi diller gelismis, resque ve akka gibi library'ler cikmis, java gibi diller concurrency paketleri gelistirmislerdir(promise, future zart zurt). bu esnada adam gibi threading mekanizmasi olmayan php gibi diller de onemli web stacklerinden uzak tutulmaya baslamislardir.
• multi thread mimarisi ile asenkron programlamanin bu baslikta bile karistirildigini dusunuyorum. asenkron programlama musteri-servis elemani iliskisinden ziyade, servis elemani-mutfak iliskisini duzenler. servis elemaninin siparis hazirlanana kadar o siparis ile ilgilenmeyip hazirlanma esnasinda diger islerede bakabilmesine olanak verir.
• konsept olarak asynchronous flowlar yuksek maliyetli operasyonlarin optimize edilmesinde kullanilir.
  
  embesiller icin en uygun anlatim sekli pastane isletmesidir. pastanede ekmek , borek corek ve pasta satacaksiniz diyelim. her musteri geldiginde tamam ben sana bir ekmek, corek pisireyim derseniz, adami yarim saat bekletirsiniz, bir daha da size gelmez. o yuzden bunlarin hepsini aksamdan yaptiniz ve satisa cikardiniz. herkes gelip guzel guzel aksamdan yaptiklarinizi alip gidiyor. iste bu birinci async turu oluyor. teori de herkes mutlu.
  
  sonra bazi musterileriniz geldi, aa bana uzerine tarih yazili pasta lazim, isim yazili pasta lazim dedi .. e bunu aksamdan yapamazsiniz, o arkadasa sizin isi siraya aldim, yarin gelin su saatte pastanizi alin diyorsunuz. bu da ikinci async turu oluyor.
  
  bunu system design acisindan ele alirsak, sisteme gelen istekler az maliyetli operasyonlar ise ( sistem kaynaklari acisindan ) bunlari direk isleme alip onceden hazirlanmis data set uzerinden yanit verip ( hatirliyoruz, birinci tur async islemler ) , yuksek maliyetli operasyonlari ( yine sistem kaynaklari acisindan ) arkada planda queue benzeri bir yapiya atip, diger yuksek maliyetli islemler ile beraber sirali halde process etmeye dayanir ( ikinci tur async islemler ) bu sayede sistem kaynaklari ( cpu, thread , vcpu, etc ) optimize edilerek kullanilir
• swift özelinde bir çalışma için raywenderlich.com ekibi tarafından hazırlanmış ve yayınlanmış güzel bir kitap olarak combine: asynchronous programming with swift'e bakılabilir.
  
  kolay bir kaç google aramasıyla full versiyonun ücretsiz pdfleri de bulunabilmektedir.
  
  ayrıca, kitaba dair open-source github reposu için:
  github/kitap
• kısaca bir işlem yaptırdığınız fonksiyonunuz var ve bu fonksiyon kullanıcı o işlemi sizden yapılmasını istediğinde çalışması gerekiyor olsun.
  
  klasik programlama ile, bir döngü yazarsınız bunun içine koşul sağlanana kadar istek var mı diye kontrol et dersiniz. koşul olsada olmasada programınız arka planda kontrol işlemi gibi işlemler için kaynak tüketmeye devam eder. koşuldan çıkılamadığı için programınızın geri kalanındaki kodlarınız çalıştıramazsınız ve isteği bekler durursunuz. arka planda ram ve işlemciler ise israf ediliyor bu sırada.
  
  bu asenkron programlama ile bu istek yokken gereksiz olarak arka planda gereksiz kaynak tüketiminin önüne geçiliyor. mantık habire arka planda kontrol et yerine sadece istek varsa şu işlemi yap şeklinde ana programınızdan bağımsız , bütünden kopuk, asenkron olarak çalışan kontrol işlemine bölünmüş oluyor.
  
  yani istek gelene kadar istek varmı kontrol et yerine, programınızdan bağımsız olarak bir işlem tanımlıyorsunuz ve sadece buna doğru istek geldiğinde 1 kere çalışıp işini hallet diyorsunuz.
  
  özellikle çok çekirdekli işlemciler aynı anda çekirdek sayısı kadar farklı komutu işletebildiklerinden bu programlama modeli ile programın bütünü o kontrol işleminin sonucunu beklemekten kurtuluyor ve diğer programın kaynaklarını sömürmüyor, sadece işini yapıyor. bu sırada kullanıcı arkaplanda istediği işlemi yapabiliyor.
  
  örnek kullanım alanı olarak ağ istekleri verilebilir. ağ isteği yokken arka planda ağ isteği varmı diye kontrol etmek yerine normal programınızdan ayrı bir asenkron işlem tanımlıyorsunuz sadece bu işleme istek geldiğinde programınızın gerekli işlemi devreye sokuyor ve işlemi tanımlıyor. bu sayede gereksiz kaynak tüketiminin önüne geçiliyor.
  
  flutterda ki stream yapısı mobil programlama için güzel bir örneği bu programlama mantığının.
• (bkz: non-blocking)
• php ile nasıl yapılır diye düşünürken stackoverflowda mantıklı bir yolunu bulduğum programlama tarzıdır.
  direkt alıntılıyorum;
  you are not specifying what language the asynchronous call is in, but ı'm assuming php on both ends. ı think the most elegant way would be this:
  
  html page loads, defines a random key for the operation (e.g. using rand() or an already available session ıd [be careful though that the same user could be starting two operations])
  
  html page makes ajax call to php script to start_process.php
  
  start_process.php executes exec /path/to/scriptname.php to start the process; see the user contributed notes on exec() on suggestions how to start a process in the background. which one is the right for you, depends mainly on your os.
  
  long_process.php frequently writes its status into a status file, named after the random key that your ajax page generated
  
  html page makes frequent calls to show_status.php that reads out the status file, and returns the progress.
• silverlight ile dibine vurulur. ozellike web servislerine yapilan her cagrinin asenkron olmasi cilgincasinadir.
• yoğun veri kullanan uygulamalarda performans için vazgeçilmez bir zorunluluk da olsa, io işlemlerinin başarıyla tamamlanması ile işlemin tamamlandığının bildirilmesi arasındaki ilişkiyi kopardığı için beklenmedik hata senaryolarının daha en baştan çok iyi ele alınmasını gerektiren bir programlama türüdür. aksi takdirde her şeye "eyvallah" diyip bilmem ne veritabanı problemi yüzünden aslında arka planda hiçbir şey yapmayan uygulamalarla uğraşmanıza neden olabilir. io işlemlerini asenkron olarak takip eden thread'lerin mümkün olduğunca "atomic" yapıda olması zorunludur.