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
• 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.
• asenkron programlama nasıl olmazı anlatan güzel bir video : async programming