Tekrar hoş geldiniz çocuklar.
Şimdi sorduğum basit ve anlaşılır bir soru, çok iş parçacıklı uygulamaların eşdeğer
tek iş parçacıklı uygulamalara kıyasla her zaman daha üstün olup olmadığıdır.
Sizce doğru olan nedir? Yani bunlar çok iş parçacıklı, her zaman tek iş
parçacıklıdan daha üstün olan mülakat soruları mı? Ve çok iş parçacıklı uygulamalar tek
iş parçacıklı uygulamalara kıyasla her zaman daha iyi performans gösterir mi? Basit
ve doğrudan cevap, uygulamadaki izole veri yapılarının ve bağımsız sorumlulukların derecesi ne
kadar fazlaysa, uygulamaların çok iş parçacıklı olma eğiliminin o kadar fazla olduğudur.
Uygulamaların veri yapılarının izole olması, birbirlerine bağımlı olmadıkları anlamına gelir.
Eğer bir veri yapısını güncellersek, bu bir sonraki veri yapısının güncellenmesini tetiklemez.
O zaman bu tür veri yapıları izole veri yapıları olarak adlandırılır.
Tamam.
Ve uygulama mantığınız bağımsız sorumluluklara bölünebiliyorsa, bu, uygulamanızın bağımsız iş
parçacıkları tarafından yürütülebileceği ve bu türlerin bağımsız olduğu anlamına gelir.
Yani, birbirlerine müdahale etmezler.
O halde böyle bir uygulama çok iş parçacıklı olmalıdır, bu kadar basit.
Böylece görevlere gerçekleştirmeleri için bağımsız görevler atanabilir ve üçlüler
birbirleriyle etkileşime girmeden izole edilmiş veriler üzerinde çalışır.
Müdahale etmek derken, kabilelerin birbirleriyle herhangi bir ağırlık
ve sinyalleşme yapmak zorunda olmadıkları anlamına geliyor.
Yani, üçüncü bir senkronizasyon ya da tehdit işbirliği yoktur çünkü buna
gerek yoktur çünkü iplikçiğin üzerinde çalıştığı yapılar tamamen izole edilmiştir.
Her iş parçacığı, üzerinde işlem yapması gereken veri yapılarının kendi kopyasına sahiptir.
Bu yüzden bekleyip birbirimize sinyal vermeyi deneyeceğim.
Yani bu, resimde görebileceğiniz gerçek dünya örneğine benzer.
Sol tarafta, arabalar iş parçacıklarını temsil eder ve bu kartlar daha
yavaş hareket eder çünkü arabalar arasında paylaşılan kaynak olan yol sıkışıktır.
Pekala, bir araba yavaşça hareket ediyor, sadece yakındaki diğer bir araba ona yer açıyor.
Tamam.
Dolayısıyla, Sean ve sol taraf gibi trafik sıkışıklığına takıldığınızda,
bir saat içinde yalnızca beş km ilerleme eğiliminde olabilirsiniz.
Aslında bu, Hindistan'daki Bangalore gibi metro şehirlerinde yaygın bir senaryodur.
Pekala, zamanının zirvesinde.
Oysa bizim lüks hayatımızın tadını çıkaran bu
adam, buradaki kaynaklara özel bir erişime sahip.
Kaynaklar, yoldan başka bir şey yok.
Tamam.
Aynı kaynağa erişimde rekabet yoktur ve bu
nedenle beş kilometreyi 10 dakikada kat edebilir.
Dolayısıyla, bunun sol tarafta tek bir kaynağın çok sayıda kullanıcısı
olduğu ve bu nedenle her kullanıcının aynı kaynağa erişmek için
diğerleriyle işbirliği yapmak zorunda olduğu adil bir benzetme olduğunu görebilirsiniz.
Bu işbirliğini gerçekleştirmek için de bir gecikme yaşanması gerekiyor.
Tamam.
Bu da basitçe, uygulamanız çok iş parçacıklı ise, birden fazla iş
parçacığının aynı kaynağımız için rekabet etmesi ve rekabetin çok yüksek olması
durumunda uygulamanızın daha iyi performans göstermesinin gerekli olmadığı anlamına gelir.
Rekabet çok yüksek dediğimde, iş parçacığı sayısının yeterince büyük
ve kaynak sayısının yeterince düşük olduğu anlamına gelir, bu
durumda çok izlenen program çok kötü performans gösterecektir.
Programınızın enerjisinin çoğu sadece ağırlık ve ipliklere sinyal vermek için harcanacaktır.
Tamam.
Bu nedenle, bu tür senaryolarda uygulamanızı tek iş parçacıklı olarak uygulamak daha iyidir, bu
tür senaryolarda tek iş parçacıklı bir uygulamadan daha iyi bir performans elde edecektiniz.
Şimdi bir sonraki slayta geçerek, uygulamanızın çok iş parçacıklı mı yoksa
tek iş parçacıklı mı olması gerektiğine karar vermek için uygulamanızın sahip
olması gereken özelliklerin neler olduğunu vurgulayalım. Diyelim ki Abby yeni bir
uygulama tasarlamak istiyor ve tek iş parçacıklı mı yoksa çok
iş parçacıklı mı bir uygulama tasarlaması gerektiği konusunda kafası karışık.
Yanlış iplik modelini seçmenin uzun vadede yıkıcı olacağını unutmayın.
Uygulama için yanlış iş parçacığı modelini seçerseniz, zamanın bir
noktasında uygulamanızın yönetilmesinin çok zor hale gelmesi saçma olabilir.
Yani ileride, eğer.
Uygulamanın boyutu çok büyük.
Yani, uygulamanız, binlerce satıra dağılmış yüz milyonlarca kod satırını,
bu uygulamayı çok katmanlı olarak uygulamaktan, bu uygulamayı çok
iş parçacıklı bir uygulama olarak uygulamaktan daha fazla söylüyor.
O zaman küçük bir hata ve iş parçacığı senkronizasyonu bile kilitlenmeye yol açacaktır.
Yani bu olumlu bir nokta, uygulamanızın boyutu büyükse,
uygulamanızı tek iş parçacıklı olarak kodlamaya çalışın.
Ancak elbette bu kriter tek kriter değildir.
Uygulamanızın boyutunun çok büyük olduğunu ve tek iş parçacıklı gnome olarak kodlandığını söylüyor.
Bu, faktörlerden sadece bir tanesidir.
Bakalım elimizde başka hangi faktörler var.
Ve uygulamanız orta büyüklükteyse, doğru
senkronizasyonu uygulamak ve yönetmek kolaydır.
Unutmayın, senkronizasyon programlarını takip etmek için programları yönetmek zordur.
Ekibinize yeni bir işe alım uzmanı aldınız ve o sadece sinyalimizi
beklemek için yanlış bir arama yaptı ve başvurunuzun çıkmaza girdiğini duydu.
Tamam.
Dolayısıyla, orta büyüklükteki bir uygulama bir kez daha çok iş parçacıklı olmaya adaydır, ancak
uygulamanızın çok iş parçacıklı olup olmayacağına karar vermek için tek kriter bu değildir.
Bu, uygulamanızın çok iş parçacıklı olarak kodlanıp kodlanmaması gerektiğini düşünmek için sadece olumlu bir noktadır.
Diğer bir nokta ise, eğer uygulamanız örtüşen veri yapıları içeriyorsa, örtüşen
veri yapılarının ne olduğunu daha önce açıklamıştık, o zaman uygulamanız iş
parçacıkları arasında çok fazla kilitleme ve kilit açma ile sonuçlanacaktır.
İş parçacıkları arasında çok fazla ağırlık ve sinyalleşme olacaktır, bu nedenle bu
sizi uygulamanızı tek iş parçacıklı olarak uygulamaya itme eğiliminde olan bir noktadır.
Bununla birlikte, uygulamanız izole edilmişse, veri standı ve terk
edilmiş parçalar bu veri yapıları üzerinde mevcut işlemleri gerçekleştirebilir.
Bu da uygulamanızın çoklu iş parçacıklı olarak uygulanmasını vurgulayan olumlu bir noktadır.
Benzer şekilde, uygulamanız mantık veya işleme arasında net bir ayrım göstermiyorsa, paralellik kapsamı
olmadığı anlamına gelir, o zaman elbette tek iş parçacıklı bir tasarıma gitmeniz gerekir.
Bunun tam tersi ise, uygulamanızda mantık veya işlem sınırı
açıkça varsa, bu uygulamanızın bağımsız modüllere ayrılabileceği anlamına gelir.
Daha sonra her modül bağımsız olarak uygulanabilir, belirli bir sorumlulukla
denenebilir ve böyle bir uygulama çok iş parçacıklı olarak uygulanabilir.
Diğer bir faktör de uygulamalarınızın sıralı görevler gerçekleştirip gerçekleştirmediğidir, eğer uygulama mantığınız D1
görevini, ardından veri görevini ve ardından D3 görevini tam olarak aynı sırada
gerçekleştirmenizi gerektiriyorsa, bu tür uygulamalar tek iş parçacıklı bir uygulama olarak kodlanmalıdır.
İş parçacıkları sırasında Görev D'yi iki veya üç paralel olarak yürütemezsiniz.
Tamam.
Oysa uygulamanız mülk operatörü görevinde uzman ise.
Yani bu nokta ve bu nokta neredeyse örtüşen
noktalar aslında aynı şey olabilir mi? Paralel atımların
olduğu bu tür uygulamalar multithreading olarak uygulanma eğilimindedir.
Dolayısıyla, uygulanacak bir uygulama göz önüne alındığında, geliştiricinin tüm
bu cephelerde uygulama tasarımını ve yapısını değerlendirmesi gerekir.
Ve sonunda bir uygulamanın tek iş parçacıklı mı yoksa
çok iş parçacıklı mı olması gerektiğine karar verilmesi gerekir.
Ve unutmayın, bu kararın daha uygulamanın ilk kod satırını yazmadan
önce alınması gerekir ve yanlış karar bu noktada alınır.
Uygulamanın tüm uygulamasını çöpe atacağız.
Yirmi yıldan bu yana uygulamaları uygulayan ve sürdüren şirketler var.
Tamam.
Dolayısıyla, uygulamalarının tek iş parçacıklı mı yoksa çok iş
parçacıklı mı kodlanması gerektiği kararı yirmi yıl önce alınmıştır.
Size pratik bir örnek ya da gerçek bir örnek vereyim.
Diyelim ki X şirketimiz var. Şimdi bu X gerçek bir şirket.
Sadece şirketin gerçek adını almak istemiyorum.
Ve bu X Şirketi yönlendirme protokollerini ya da diyelim ki yönlendirme protokolünü uygulamaya koydu.
Diyelim ki ISIS, diyelim ki yönlendirme protokolü veya SBF yönlendirme protokolü, diyelim ki
BGP vs. vs. Yani bu yönlendirme protokolleri X Şirketi tarafından uygulanan uygulamalardır.
Bu uygulamalar X Şirketi tarafından yirmi yılı aşkın bir süredir ödüllendirilmektedir. Bu,
şirketin aslında bu protokollerin her birinin uygulanmasına neredeyse 1995 yılında başladığı ve
bugün bile bu uygulamaların geliştiriciler veya mühendisler tarafından geliştirildiği anlamına gelmektedir.
Şimdi, 1995 yılında, şirket bu protokolleri tek iş parçacıklı mı yoksa çok iş
parçacıklı mı uygulamak istediğine ve bunu olay döngüleri kullanarak mı yoksa C veya
C++ veya başka bir programlama dili kullanarak mı uygulamak istediğine karar verdi.
Bu karar 1995 yılında alınmıştır ve bu karar bir kez alındıktan sonra
değiştirilemez çünkü uygulamayı hayata geçirmeye başladıktan sonra uygulamanın en iyi tasarımı değiştirilemez.
Bu çok maliyetli ya da çok zor.
Dolayısıyla, uygulamanın temel tasarımını değiştirmek, örneğin, uygulamanın geliştirilmesinin üzerinden
on yıl geçmişken uygulamayı tek iş parçacıklıdan çok iş
parçacıklıya dönüştürmek, şirkete yüz milyonlarca dolara mal olacaktır, aslında
bu şirket için yapılabilir bir iş bile değildir.
Diyelim ki şimdi yeni gelişen programlama dili rust, yeni sistem
programlamaya adapte edilmesi gereken yeni nesil bir dil olarak görülüyor.
Şimdi, diyelim ki şirket Protokol I'i C'de uyguladı ve aradan yirmi yıl geçti.
Ve şimdi bu özel assize, diyelim ki iki milyon satır kod.
Yani artık şirket, protokolün gözlerinin kod tabanını tohumdan pasa değiştirmeyi göze alamıyor.
Bunu yapamaz.
Bu mümkün değildir.
Dolayısıyla, yeni bir programlama dilinin piyasaya sürülmesi
mevcut programlama dilini modası geçmiş hale getirmez.
Quora'da sık sık programlama dilinin modasının geçip geçmediğine dair bazı
web siteleri görüyorum, basitçe, sistem programlama yapmak veya programlama alanında
ısrar etmek açısından görmeye daha yakın bir programlama dili yok.
Rust çok gelecek vaat eden bir dildir ve büyük
olasılıkla bu dil birçok yeni şirket tarafından benimsenecektir.
Ancak, son birkaç on yıldır şirketler tarafından geliştirilen mevcut kod
tabanlarımız, C gibi mevcut programlama dillerinde uygulandıktan sonra, bu kod
tabanlarını rust gibi yeni programlama dillerine dönüştürmek neredeyse imkansızdır.
Çünkü iş açısından bakıldığında, müşteri kendisine teslim
edilen ürünün paslanıp paslanmadığını pek umursamaz.
Şirket, bir programlama dilinde uygulanan bir kod tabanını diğerine dönüştürmek veya bu zayıf tabanı bir
iş parçacığı modelinden diğerine dönüştürmek olan bu alıştırmayı yapmaktan herhangi bir kar elde etmiyor.
İşte bu, sizlerle paylaşmak istediğim sektörel bir seviye.
Aslında konudan biraz detay aldık ama yine de iyi bir tartışma oldu.