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.
• 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.
• (bkz: node.js)
• (bkz: non-blocking)
• silverlight ile dibine vurulur. ozellike web servislerine yapilan her cagrinin asenkron olmasi cilgincasinadir.
• 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.
• bilmeyene anlatması zor bir konsept hatta mvpler bile stajyerlere anlatamıyormuş bazen. buyrun 2 yaşında çocuğun bile anlayabileceği şekilde anlatımı:
  https://www.youtube.com/watch?v=8l1a-_c8mcg
• asenkron programlama nasıl olmazı anlatan güzel bir video : async programming
• 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