GÇ eşzamanlı eşzamansız engellemesiz engelleme arasındaki fark
Eşzamanlı GÇ ve eşzamansız GÇ nedir, GÇ'yi engelleyen ve GÇ'yi engellemeyen GÇ nedir ve aralarındaki fark nedir?
Aslında, farklı insanlar bu soruya farklı cevaplar verebilirler.Örneğin, wiki eşzamansız IO'yu ve engellemeyen IO'yu tek bir şey olarak kabul eder. Bunun nedeni, bu konuyu tartışırken farklı insanların farklı bilgi geçmişlerine ve farklı bağlamlara sahip olmalarıdır. Dolayısıyla, bu soruyu daha iyi cevaplayabilmek için öncelikle bu makalenin içeriğini sınırlandırıyorum.
Bu makalede tartışılan arka plan, Linux ortamındaki ağ GÇ'sidir.
Bu makaledeki en önemli referans Richard Stevens'ın "UNIX® Network Programming Volume 1, Third Edition: The Sockets Networking", Bölüm 6.2 "G / Ç Modelleri" dir. Stevens, bu bölümde çeşitli IO'ların özelliklerini ve farklılıklarını ayrıntılı olarak açıkladı. , İngilizce yeterince iyiyse, doğrudan okumanız tavsiye edilir. Stevens'ın yazı stilinin derin şeyleri basit bir şekilde açıkladığı bilinmektedir, bu yüzden anlamamak konusunda endişelenmeyin. Bu makaledeki akış şeması da referanslardan kesilmiştir.
Stevens, makaledeki toplam beş IO Modelini karşılaştırdı:
GÇ'yi engelleme
engellemeyen GÇ
IO çoğullama
sinyal odaklı IO
eşzamansız GÇ
Uygulamada sinyal güdümlü IO yaygın olarak kullanılmadığından, sadece kalan dört IO modelinden bahsedeceğim.
IO gerçekleştiğinde dahil olan nesneler ve adımlar hakkında konuşmama izin verin.
Bir ağ IO için (burada örnek olarak okuyacağız), iki sistem nesnesi içerecektir, biri IO'yu çağıran süreç (veya iş parçacığı), diğeri ise sistem çekirdeğidir (çekirdek). Bir okuma işlemi gerçekleştiğinde, iki aşamadan geçecektir:
1 Verilerin hazır olması bekleniyor
2 Çekirdekteki verileri işleme kopyalayın (Çekirdekteki verileri işleme kopyalamak)
Bu iki noktayı hatırlamak önemlidir, çünkü bu IO Modelleri arasındaki fark, iki aşamada farklı durumlara sahip olmalarıdır.
GÇ'yi engelleme
Linux'ta tüm soketler varsayılan olarak engellenir. Tipik bir okuma işlemi akışı kabaca şu şekildedir:
Kullanıcı süreci recvfrom sistem çağrısını çağırdığında, çekirdek IO'nun ilk aşamasına başlar: verilerin hazırlanması. Ağ io için, çoğu zaman veri başlangıca ulaşmaz (örneğin, tam bir UDP paketi alınmamıştır), bu sırada çekirdeğin yeterli verinin gelmesi için beklemesi gerekir. Kullanıcı süreci tarafında, tüm süreç engellenecektir. Çekirdek, veriler hazır olana kadar beklediğinde, verileri çekirdekten kullanıcı belleğine kopyalar ve ardından çekirdek sonucu döndürür ve kullanıcı işlemi blok durumunu serbest bırakır ve yeniden başlatır.
Bu nedenle, GÇ'yi engellemenin özelliği, GÇ yürütmesinin her iki aşamasında da engellenmesidir.
Engellemesiz GÇ
Linux altında, soketi ayarlayarak engellemesiz hale getirebilirsiniz. Tıkanmayan bir soket üzerinde bir okuma işlemi gerçekleştirirken, işlem şu şekilde görünür:
Kullanıcı işlemi bir okuma işlemi yaptığında, çekirdekteki veriler hazır değilse, kullanıcı işlemini engellemeyeceği ancak hemen bir hata döndüreceği şekilden görülebilmektedir. Kullanıcı süreci açısından bakıldığında, bir okuma işlemi başlattıktan sonra beklemesi gerekmez, hemen sonuç alır. Kullanıcı süreci sonucun bir hata olduğuna karar verdiğinde, verinin hazır olmadığını bilir, böylece okuma işlemini tekrar gönderebilir. Çekirdekteki veriler hazır olduğunda ve kullanıcı işleminden sistem çağrısını tekrar aldığında, verileri anında kullanıcı belleğine kopyalar ve ardından geri döner.
Bu nedenle, kullanıcı işleminin aslında sürekli olarak çekirdek verilerini aktif olarak istemesi gerekir.
IO çoğullama
IO çoğullama terimi biraz yabancı olabilir, ancak seç, epoll dersem, muhtemelen anlayabilirim. Bazı yerlerde, bu GÇ yöntemine olay odaklı GÇ de denir. Hepimiz, select / epoll'un avantajının, tek bir işlemin birden fazla ağ bağlantılı IO'yu aynı anda idare edebilmesi olduğunu biliyoruz. Temel ilkesi, select / epoll işlevinin sorumlu olduğu tüm soketleri sürekli olarak sorgulaması ve bir soket veri geldiğinde, kullanıcı sürecini bilgilendirmesidir. İşlemi şekilde gösterilmiştir:
Kullanıcı çağrıları seçtiğinde, tüm süreç engellenecek ve aynı zamanda çekirdek, seçimden sorumlu tüm soketleri "izleyecek". Herhangi bir soketteki veriler hazır olduğunda, select dönecektir. Bu sırada, kullanıcı işlemi, verileri çekirdekten kullanıcı işlemine kopyalamak için okuma işlemini yeniden çağırır.
Bu resim, engelleyici IO resminden çok farklı değil, aslında daha da kötü. Burada iki sistem çağrısının (seçme ve geri alma) kullanılması gerektiğinden ve GÇ'yi engellemek yalnızca bir sistem çağrısını (geri alma) çağırır. Ancak, select kullanmanın avantajı, aynı anda birden çok bağlantıyı idare edebilmesidir. (Bir cümle daha. Dolayısıyla, işlenen bağlantı sayısı çok yüksek değilse, select / epoll kullanan web sunucusu, multi-threading + blocking IO kullanan web sunucusundan mutlaka daha iyi olmayabilir ve gecikme daha da fazla olabilir. Select / epoll Avantajı, tek bir bağlantıyı daha hızlı idare edebilmesi değil, daha fazla bağlantıyı idare edebilmesidir.)
IO çoğullama Modelinde, pratikte, her bir soket genellikle engellemesiz olarak ayarlanır, ancak yukarıdaki şekilde gösterildiği gibi, tüm kullanıcı süreci aslında her zaman bloke edilir. Sadece işlem, bloğa soket IO tarafından verilmek yerine işlev bloğu tarafından seçilir.
Eşzamansız G / Ç
Linux altında asenkron IO nadiren pratiktir. İlk önce sürecine bakın:
Kullanıcı işlemi okuma işlemini başlattıktan sonra, hemen başka şeyler yapmaya başlayabilir. Öte yandan, çekirdek açısından, eşzamansız bir okuma aldığında, önce hemen geri dönecek, böylece kullanıcı işlemine herhangi bir blok oluşturmayacaktır. Daha sonra çekirdek, veri hazırlığının tamamlanmasını bekleyecek ve daha sonra verileri kullanıcı belleğine kopyalayacaktır.Tüm bunlar tamamlandığında, çekirdek, kullanıcı işlemine okuma işleminin tamamlandığını bildiren bir sinyal gönderecektir.
Şimdiye kadar dört IO Modeli de tanıtıldı. Şimdi ilk birkaç soruyu yanıtlamak için geri dönün: Engelleme ve engellememe arasındaki fark nedir ve eşzamanlı GÇ ile eşzamansız GÇ arasındaki fark nedir.
Önce en basit olanı yanıtlayın: engelleme ve engellememe. Aslında önceki giriş, ikisi arasındaki farkı açıkça açıklamıştı. Engelleme GÇ'sinin çağrılması, işlem tamamlanana kadar ilgili işlemi engeller ve engellemeyen GÇ, çekirdek hala veri hazırlarken hemen geri döner.
Senkron IO ile asenkron IO arasındaki farkı açıklamadan önce, her ikisinin de tanımını vermemiz gerekiyor. Stevens tarafından verilen tanım (aslında POSIX tanımı) şuna benzer:
Eşzamanlı bir G / Ç işlemi, talep eden işlemin G / Ç işlemi tamamlanıncaya kadar engellenmesine neden olur;
Eşzamansız bir G / Ç işlemi, talep eden işlemin engellenmesine neden olmaz;
İkisi arasındaki fark, senkronize IO'nun "IO işlemi" yaparken süreci bloke etmesidir. Bu tanıma göre, yukarıda bahsedilen bloke edici IO, bloke edici olmayan IO ve IO multiplekslemenin tümü senkronize IO'ya aittir. Birisi engellemeyen GÇ'nin engellenmediğini söyleyebilir. Burada çok "kurnaz" bir yer var. Tanımdaki "IO işlemi", örnekteki recvfrom sistem çağrısı olan gerçek IO işlemini ifade ediyor. Engellemesiz GÇ, geri alma sistem çağrısını yürüttüğünde, çekirdek verileri hazır değilse, işlem şu anda engellenmeyecektir. Ancak çekirdekteki veriler hazır olduğunda, recvfrom verileri çekirdekten kullanıcı belleğine kopyalayacaktır.Bu sırada işlem engellenir.Bu süre zarfında işlem engellenir. Eşzamansız GÇ farklıdır.İşlem bir GÇ işlemini başlattığında doğrudan geri döner ve çekirdek, işleme GÇ'nin tamamlandığını bildiren bir sinyal gönderene kadar onu tekrar yok sayar. Tüm bu süreç boyunca, süreç hiç engellenmedi.
Her bir GÇ Modelinin karşılaştırması şekilde gösterilmektedir:
Yukarıdaki girişten sonra, engellemeyen GÇ ile eşzamansız GÇ arasındaki farkın hala çok açık olduğunu göreceksiniz. Bloke edilmeyen IO'da, süreç çoğu zaman engellenmeyecek olsa da, yine de işlemin aktif olarak kontrol edilmesini gerektirir ve veri hazırlığı tamamlandığında, işlemin verileri kullanıcı belleğine kopyalamak için tekrar recvfrom çağrısı yapması gerekir. . Eşzamansız GÇ tamamen farklıdır. Bu, kullanıcı işleminin tüm IO işlemini tamamlamak için başka birine (çekirdek) devretmesi gibidir ve sonra diğer kişi tamamlandığında bir sinyal gönderecektir. Bu süre boyunca, kullanıcı işleminin IO işleminin durumunu kontrol etmesi veya verileri aktif olarak kopyalamasına gerek yoktur.
