Çok iş parçacıklı bir JavaScript çalışma zamanı uygulaması yapmanın sakıncaları nelerdir? [kapalı]

Geçen hafta boyunca çok iş parçacıklı bir JavaScript çalışma zamanı uygulaması üzerinde çalışıyorum. JavaScript ++ 'u kullanarak C ++' da yapılmış bir konsept kanıtım var.

Mimari basittir: çalışma zamanı ana betiği değerlendirmeyi bitirdiğinde, bir iş parçacığı havuzunu başlatır ve birleştirir; bu, paylaşılan bir öncelik sırasından görevleri seçmeye başlar, iki görev aynı anda değişkene erişmeye çalışırsa, atomik olarak işaretlenir ve erişim için çalışırlar. .

Sorun şu ki, bu tasarımı bir JavaScript programcısına gösterdiğimde son derece olumsuz geri bildirim alıyorum ve nedenini bilmiyorum. Özel olarak bile, hepsi JavaScript'in tek bir iş parçacığı olduğunu, mevcut kütüphanelerin yeniden yazılması gerektiğini ve bunun üzerinde çalışmaya devam edersem her canlıyı ortaya çıkaracaklarını ve gremlinlerin doğacağını söylüyorlar.

Başlangıçta yerli bir coroutine uygulaması da yaptım (artırma bağlamlarını kullanarak), ama onu kesmek zorunda kaldım (JavaScriptCore yığın hakkında bilgilidir) ve gazaplarını riske atmak istemedim, bu yüzden bahsetmeme karar verdim.

Ne düşünüyorsun? JavaScript tek bir iş parçacığı olarak mı kastediliyor? Neden herkes eşzamanlı bir JavaScript çalışma zamanı fikrine karşı?

Düzenleme: Proje şimdi GitHub'da , kendiniz deneyin ve ne düşündüğünüzü bana bildirin.

Aşağıdakiler, hiçbir çekişmeden paralel olarak tüm CPU çekirdeğinde çalışan sözlerin bir resmidir:

1) Multithreading son derece zor ve ne yazık ki bu fikri şu ana dek sunma şekliniz, bunun ne kadar zor olduğunu ciddiye aldığınız anlamına geliyor.

Şu anda, kulağa dile sadece "konu ekliyorsunuz" ve nasıl doğru ve performans göstereceğine dair endişe duyuyorsunuz. Özellikle:

Eğer iki görev aynı anda bir değişkene erişmeye çalışırsa, atomik olarak işaretlenir ve erişim için yarışırlar.
...
Atom değişkenlerinin her şeyi çözmeyeceği konusunda hemfikirim, ancak senkronizasyon problemi için bir çözüm üzerinde çalışmak bir sonraki hedefim.

Javascript'e "senkronizasyon problemi için çözüm" olmadan konu eklemek, Javascript'e "ekleme problemi için çözüm" olmadan tamsayı eklemek gibidir. Sorunun doğası için o kadar temeldir ki, temelde okuyucunun belirli bir çözüm olmadan eklemeye değip değmeyeceğini, ne kadar çok istersek isteyelim, tartışmanın hiçbir anlamı yoktur.

Ayrıca, tüm değişkenleri atomik yapmak, çok iş parçacıklı bir programın tek parçalı iş parçasından daha kötü performans göstermesine neden olacak bir şeydir; bu , daha gerçekçi programlardaki performansı test etmeyi ve bir şey kazanıp kazanmadığınızı görmeyi daha da önemli kılar.

Ayrıca, düğümleri node.js programlayıcısından gizli tutmaya mı çalışıyorsunuz, yoksa bir noktada açıklamayı planlıyorsanız, okuyuculu programlama için yeni bir Javascript lehçesini etkili bir şekilde hazırlıyorsanız, bu da açık değildir. Her iki seçenek de potansiyel olarak ilginç, ancak henüz hangisini hedeflediğinize karar vermemiş gibisiniz.

Şu anda, programcılardan, tek kullanımlık bir ortamdan, senkronizasyon sorunu için bir çözümü olmayan ve gerçek dünya performansını artırdığına ve bu sorunların çözülmesine yönelik bir planı bulunmadığına dair kanıt içermeyen yepyeni bir okuyuculu ortama geçmeyi düşünmelerini istiyorsunuz.

Muhtemelen bu yüzden insanlar seni ciddiye almıyorlar.

2) Tek olay döngüsünün sadeliği ve sağlamlığı çok büyük bir avantajdır.

Javascript programcıları Javascript dilinin yarış koşullarından ve hepsi gerçekten çok iş parçacıklı programlamayı rahatsız eden diğer son derece sinsi böceklerden "güvenli" olduğunu bilirler. Güvenlikten vazgeçmeleri için onları ikna etmek için güçlü argümanlara ihtiyaç duymaları gerçeği kapalı fikirli olmalarını sağlamaz, onları sorumlu yapar.

Bu güvenliği bir şekilde koruyamazsanız, çok iş parçacıklı bir node.js'ye geçmek isteyebilecek herhangi biri, çok iş parçacıklı uygulamalar için sıfırdan tasarlanmış Go gibi bir dile geçiş yapmaktan muhtemelen daha iyi olacaktır.

3) Javascript, doğrudan programcıya konu yönetimi göstermeden "arka plan konuları" (WebWorkers) ve zaman uyumsuz programlamayı desteklemektedir.

Bu özellikler, tek olay döngüsünün güvenliğinden vazgeçmeden, gerçek dünyadaki Javascript programcılarını etkileyen yaygın kullanım durumlarının çoğunu zaten çözmektedir.

Bu özelliklerin çözülmediğini ve Javascript programcılarının bunun için bir çözüm istediğini düşündüğünüz özel kullanım durumlarınız var mı? Öyleyse, çok iş parçacıklı node.js kodunuzu bu belirli kullanım durumu bağlamında sunmak iyi bir fikirdir.

PS Çok iş parçacıklı bir node.js uygulamasına geçmeyi denemek için beni ne ikna eder?

Javascript / node.js'de orijinal çoklu kullanımdan fayda sağlayacağını düşündüğünüz önemsiz bir program yazın. Bu örnek programdaki performans testlerini normal düğümde ve çok iş parçacıklı düğümünüzde yapın. Sürümünüzün çalışma süresi performansını, yanıt verebilirliğini ve birden fazla çekirdeğin kullanımını, herhangi bir hata veya dengesizlik olmadan, önemli ölçüde geliştirdiğini gösterin.

Bunu yaptıktan sonra, bence bu fikirle daha çok ilgilenen insanlar göreceksiniz.

Yaklaşımınızdaki bir sorunu göstermek için sadece burada tahmin ediyorum. Hiçbir yerde bağlantı olmadığı için gerçek uygulamaya karşı test edemiyorum ...

Değişmezler her zaman bir değişkenin değeriyle ifade edilmediğinden ve 'bir değişken' genel durumda bir kilidin kapsamı olmadığında yeterli olmadığını söyleyebilirim. Örneğin, bir değişmezliğe sahip olduğumuzu hayal edin a+b = 0(bir bankanın iki hesapla bakiyesi). Aşağıdaki iki işlev değişmezin her bir işlevin sonunda ( tek iş parçacıklı JS'de yürütme birimi) tutulmasını sağlar.

function withdraw(v) {
  a -= v;
  b += v;
}
function deposit(v) {
  b -= v;
  a += v;
}

İki konu yürütmek Şimdi, sizin çok iş parçacıklı dünyada, ne olur withdrawve depositaynı zamanda? Sağol Murphy ...

(+ = Ve - = özel olarak işleyen bir kodunuz olabilir, ancak bu hiç yardımcı olmaz. Bir noktada, bir işlevde yerel duruma sahip olacaksınız ve iki değişkeni aynı anda 'kilitlemek' mümkün olmayacak ihlal edilmek

EDIT: Kodunuz, https://gist.github.com/thriqon/f94c10a45b7e0bf656781b0f4a07292a adresindeki Go koduna semantik olarak eşdeğerse , yorumum doğru ;-)

On yıldan uzun bir süre önce, JavaScript'in mucidi Brendan Eich , kesinlikle JavaScript'in tasarım mitolojisinin birkaç kanonik belgesinden biri olan Threads Suck adlı bir makale yazdı .

Doğru olup olmadığı bir başka sorudur, ancak JavaScript topluluğunun eşzamanlılık hakkında nasıl düşündüğü üzerinde büyük bir etkisi olduğunu düşünüyorum.

Atomik erişim iş parçacığı güvenli davranışa çevrilmez.

Bunun bir örneği, genel bir veri yapısının bir hashmaha yeniden şekillendirme (örneğin bir nesneye bir özellik eklerken) veya genel bir diziyi sıralama gibi bir güncelleme sırasında geçersiz olması gerektiğidir. Bu süre zarfında, başka hiçbir iş parçacığının değişkene erişmesine izin veremezsiniz. Bu, temel olarak okuma-güncelleme-yazma çevrimlerinin tamamını tespit etmeniz ve kilitlemeniz gerektiği anlamına gelir. Eğer güncelleme önemsiz değilse, bu sorun bölgesinin durmasına neden olacaktır.

Javascript baştan beri tek dişli ve korumalı alandır ve tüm kodlar bu varsayımlar göz önünde bulundurularak yazılmıştır.

Bu, izole edilmiş bağlamlarda ve 2 ayrı bağlamın farklı dişlerde çalışmasına izin verme konusunda büyük bir avantaja sahiptir. Ayrıca, javascript yazan kişilerin yarış koşullarıyla ve diğer çok parçacıklı tuzaklarla nasıl başa çıkacaklarını bilmeleri gerekmediği anlamına gelir.

Yaklaşımınız performansı önemli ölçüde artıracak mı?

Şüpheli. Bunu gerçekten kanıtlaman gerek.

Yaklaşımınız kod yazmayı daha kolay / daha hızlı hale getirecek mi?

Kesinlikle hayır, çok iş parçacıklı kod, tek iş parçacıklı koddan daha doğru elde etmek için çoğu zaman zordur.

Yaklaşımınız daha sağlam mı olacak?

Kilitlenmeler, yarış koşulları vb. Düzeltmek için bir kabus.

Uygulamanız sadece eşzamanlılık tanıtmakla ilgili değil, aynı zamanda eşzamanlılık, yani paylaşılan değişken duruma göre eşzamanlılık uygulamak için belirli bir yol tanıtmakla ilgilidir. Tarih boyunca insanlar bu tür eşzamanlılıkları kullandılar ve bu da pek çok soruna yol açtı. Elbette, paylaşılabilir değişken durumlu eşzamanlılık kullanarak mükemmel bir şekilde çalışan basit programlar oluşturabilirsiniz, ancak herhangi bir mekanizmanın gerçek testi yapabilecekleri değil, program karmaşıklaştıkça ve daha fazla özellik programa eklendikçe ölçeklenebilir. Yazılımın bir zamanlar oluşturduğunuz ve onunla yaptığınız statik bir şey olmadığını unutmayın, zamanla gelişmeye devam eder ve herhangi bir mekanizma veya kavram olabilir.

Bu modellerin ne tür faydalar sağladığını anlamanıza yardımcı olmak için diğer eşzamanlılık modellerine bakabilirsiniz (ör: mesaj iletme).

Bu gerekli. Js düğümünde düşük seviyeli bir eşzamanlılık mekanizmasının olmaması, matematik ve biyoinformatik vb. Alanlardaki uygulamalarını sınırlar. Ayrıca, iş parçacığıyla eşzamanlılık, düğümde kullanılan varsayılan eşzamanlılık modeliyle çakışmaz. Kullanıcı arayüzleri (ve düğümler) gibi ana olay döngüsüne sahip bir ortamda iş parçacığı için bilinen bir anlambilim vardır ve bunlar hala geçerli kullanımları olan çoğu durumda kesinlikle aşırı karmaşıktır.

Elbette, ortalama web uygulamanız iş parçacığı gerektirmeyecek, ancak biraz daha az geleneksel bir şey yapmayı deneyin ve ses seviyesi düşük eşzamanlılık ilkelinin olmaması sizi hızlı bir şekilde size sunacak başka bir şeye sürükleyecektir.

Gerçekten inanıyorum çünkü farklı ve güçlü bir fikir. İnanç sistemlerine karşı gidiyorsunuz. Ağ üzerinden ağ üzerinden yapılan eşyalar kabul edilmez veya popüler olmaz. Ayrıca hiç kimse yeni bir yığına uyum sağlamak istemez. İnsanlar çok farklı şeyleri otomatik olarak reddediyorlar.

Olası gibi görünmeyen normal bir npm modülü haline getirmek için bir yol bulabilirseniz, o zaman bazı insanlar onu kullanarak alabilirsiniz.