Java ve C #, dizi sınırlarını ve işaretçi referanslarını kontrol ederek bellek güvenliği sağlar.
Önce C # ve Java'nın bunu nasıl yaptığını düşünmek önemlidir. Onlar ne dönüştürerek bunu tanımlanmamış tanımlanan davranışa içine C veya C ++ davranışı: programı çökmesine . Boş dereferences ve dizi dizini istisnaları hiçbir zaman doğru bir C # veya Java programında yakalanmamalıdır ; ilk etapta gerçekleşmemeliler çünkü program bu hataya sahip olmamalı.
Ama bence sorunuzla ne demek istediğinizi değil! Birbirini karşılıklı olarak bekleyen n iş parçacığı olup olmadığını periyodik olarak kontrol eden ve bu durumda programı sonlandıran bir "kilitlenme güvenli" çalışma zamanı yazabiliriz, ancak bunun sizi tatmin edeceğini düşünmüyorum.
Yarış koşulları ve kilitlenme olasılığını önlemek için bir programlama dilinde hangi mekanizmalar uygulanabilir?
Sorunuzla karşılaştığımız bir sonraki sorun, kilitlenmelerin aksine "yarış koşullarının" tespit edilmesinin zor olduğudur. Unutmayın, iplik güvenliğinde peşinde olduğumuz şey ırkları ortadan kaldırmak değildir . Peşinde olduğumuz şey , yarışı kim kazanırsa kazansın programı düzeltmek ! Yarış koşulları ile ilgili sorun, iki iplik tanımsız bir sırada çalışıyor olması ve ilk önce kimin bitireceğini bilmiyoruz. Yarış koşullarındaki sorun, geliştiricilerin bazı iplik işleme siparişlerinin mümkün olduğunu ve bu olasılığı hesaba katmadıklarını unutmalarıdır.
Yani sorunuz temel olarak "bir programlama dilinin programımın doğru olduğundan emin olmasının bir yolu var mı?" ve bu sorunun cevabı pratikte hayır.
Şimdiye kadar sadece sorunuzu eleştirdim. Burada vites değiştirmeye çalışın ve sorunuzun ruhunu ele alalım. Dil tasarımcılarının, çoklu iş parçacığımızla yaşadığımız korkunç durumu azaltabilecek seçimleri var mı?
Durum gerçekten korkunç! Özellikle çok zayıf bellek modeli mimarilerinde çok iş parçacıklı kodların düzeltilmesi çok, çok zordur. Neden zor olduğunu düşünmek öğretici:
- Bir süreçte birden fazla kontrol iş parçacığının akla gelmesi zordur. Bir iplik yeterince sert!
- Çok iş parçacıklı bir dünyada soyutlamalar son derece sızdı. Tek iş parçacıklı dünyada, programların gerçekte düzgün çalışmasalar bile sırayla çalışıyormuş gibi davrandıklarını garanti ederiz. Çok iş parçacıklı dünyada artık durum böyle değil; tek bir iş parçacığında görünmeyen optimizasyonlar görünür hale gelir ve şimdi geliştiricinin bu olası optimizasyonları anlaması gerekir.
- Ama daha da kötüleşiyor. C # belirtimi, bir uygulamanın tüm iş parçacıkları tarafından üzerinde anlaşılabilecek tutarlı bir okuma ve yazma sırasına sahip olması GEREKMEZ olduğunu belirtir . "Yarış" olduğu ve açık bir kazanan olduğu düşüncesi aslında doğru değil! Birçok iş parçacığında bazı değişkenlere iki yazma ve iki okuma bulunan bir durum düşünün. Mantıklı bir dünyada "yarışları kimin kazanacağını bilemeyiz, ama en azından bir yarış olacak ve birileri kazanacak" diye düşünebiliriz. Biz bu mantıklı dünyada değiliz. C #, birden çok iş parçacığının, okuma ve yazma işlemlerinin gerçekleştiği sıraya katılmamalarına izin verir ; herkesin gözlemlediği tutarlı bir dünya olması gerekmez.
Dolayısıyla, dil tasarımcılarının işleri daha iyi hale getirebileceği açık bir yol var. Modern işlemcilerin performans kazançlarını bırakın . Tüm programların, çok iş parçacıklı programların bile son derece güçlü bir bellek modeline sahip olmasını sağlayın. Bu, çok iş parçacıklı programları birçok kez daha yavaş hale getirir, bu da çok iş parçacıklı programların ilk etapta doğrudan çalışmasına neden olur: daha iyi performans için.
Bellek modelini bir kenara bırakırsak bile, çoklu iş parçacığının zor olmasının başka nedenleri vardır:
- Kilitlenmeleri önlemek için tüm program analizi gerekir; kilitlerin alınabileceği küresel düzeni bilmeniz ve program farklı kuruluşlar tarafından farklı zamanlarda yazılmış bileşenlerden oluşsa bile, bu düzeni tüm program boyunca uygulamanız gerekir.
- Çok iş parçacığını evcilleştirmek için size verdiğimiz birincil araç kilittir, ancak kilitler oluşturulamaz .
Bu son nokta daha fazla açıklama içermektedir. "Bileşilebilir" derken aşağıdakileri kastediyorum:
Diyelim ki bir çifte verilen bir int hesaplamak istiyoruz. Hesaplamanın doğru bir uygulamasını yazıyoruz:
int F(double x) { correct implementation here }
Bir int verildiğinde bir dizeyi hesaplamak istediğimizi varsayalım:
string G(int y) { correct implementation here }
Şimdi çift verilen bir dizeyi hesaplamak istiyorsak:
double d = whatever;
string r = G(F(d));
G ve F , daha karmaşık soruna doğru bir çözüm olarak oluşturulabilir .
Ancak kilitler, kilitlenmeler nedeniyle bu özelliğe sahip değildir. L1, L2 sırasına göre kilitleri alan doğru bir yöntem M1 ve L2, L1 sırasına göre kilitleri alan doğru bir M2 yöntemi yanlış bir program oluşturmadan aynı programda kullanılamaz. Kilitler, "her bireysel yöntem doğru, bu yüzden her şey doğru" diyemeyeceğiniz şekilde yapar.
Peki, dil tasarımcıları olarak ne yapabiliriz?
İlk olarak, oraya gitme. Bir programdaki birden fazla denetim iş parçacığı kötü bir fikirdir ve iş parçacıkları arasında bellek paylaşmak kötü bir fikirdir, bu yüzden onu ilk etapta dile veya çalışma zamanına koymayın.
Görünüşe göre bu bir başlangıç değil.
O zaman dikkatimizi daha temel soruya çevirelim: neden ilk etapta birden fazla iş parçacığımız var? İki ana sebep vardır ve çok farklı olmalarına rağmen, aynı şeyle sık sık ilişkilidirler. Her ikisi de gecikmeyi yönetmekle ilgili olduğu için sınırlıdırlar.
- G / Ç gecikmesini yönetmek için yanlış iş parçacıkları oluşturuyoruz. UI iş parçacığınızı kilitlemek yerine büyük bir dosya yazmanız, uzak bir veritabanına erişmeniz gerekiyor.
Kötü bir fikir. Bunun yerine, coroutines aracılığıyla tek iş parçacıklı asenkron kullanın. C # bunu güzel yapıyor. Java, pek iyi değil. Ancak , dil tasarımcılarının mevcut ürününün diş çekme problemini çözmeye yardımcı olmasının ana yolu budur. await(F # asenkron iş akışları ve diğer önceki teknik esinlenerek) C # operatör daha fazla dil içine dahil edilmektedir.
- Boştaki CPU'ları hesaplamalı ağır işlerle doyurmak için doğru şekilde iplikler oluştururuz. Temel olarak, iplikleri hafif süreçler olarak kullanıyoruz.
Dil tasarımcıları, paralellikle iyi çalışan dil özellikleri oluşturarak yardımcı olabilir. Örneğin, LINQ'nun doğal olarak PLINQ'ya nasıl genişletildiğini düşünün. Mantıklı bir kişiyseniz ve TPL işlemlerinizi oldukça paralel olan ve belleği paylaşmayan CPU'ya bağlı işlemlerle sınırlandırırsanız, burada büyük kazançlar elde edebilirsiniz.
Başka ne yapabiliriz?
- Derleyicinin en çok okunan hataları algılamasını sağlayın ve uyarılara veya hatalara dönüştürün.
C #, kilitlenmeyi beklemenize izin vermez, çünkü bu kilitlenmeler için bir reçetedir. C # değer türünü kilitlemenize izin vermez, çünkü bu her zaman yanlış bir şeydir; kutuyu kilitliyorsunuz, değeri değil. C #, bir diğer adı geçici olarak kullanırsanız sizi uyarır, çünkü diğer ad alma / bırakma anlambilimi uygulamaz. Derleyicinin sık karşılaşılan sorunları saptamasının ve önlemesinin birçok yolu vardır.
- Bunu yapmanın en doğal yolunun da en doğru yol olduğu "kalite çukuru" özellikleri tasarlayın.
C # ve Java, herhangi bir referans nesnesini monitör olarak kullanmanıza izin vererek büyük bir tasarım hatası yaptı. Bu, kilitlenmeleri izlemeyi zorlaştıran ve statik olarak önlemeyi zorlaştıran her türlü kötü uygulamayı teşvik eder. Ve her nesne başlığında bayt israf eder. Monitörlerin bir monitör sınıfından türetilmesi gerekir.
- Büyük miktarda Microsoft Research zaman ve çabası, C # benzeri bir dile yazılım işlem belleği ekleme girişimine girdi ve bunu ana dile dahil edecek kadar iyi performans göstermediler.
STM güzel bir fikir ve Haskell'de oyuncak uygulamaları ile oynadım; kilit tabanlı çözümlerden çok doğru parçaları doğru çözümlerden daha şık bir şekilde oluşturmanıza olanak tanır. Ancak, neden ölçekli çalışmanın yapılamadığını söyleyecek ayrıntılar hakkında yeterli bilgim yok; Joe Duffy'e bir sonraki görüşünde sor.
- Başka bir cevap değişmezlikten daha önce bahsetti. Etkili koroutinlerle birlikte değişmezliğiniz varsa, aktör modeli gibi özellikleri doğrudan kendi dilinizde oluşturabilirsiniz; örneğin Erlang'ı düşünün.
Analiz temelli dilleri işlemek için çok fazla araştırma yapıldı ve bu alanı çok iyi anlamıyorum; üzerinde birkaç makale okumaya çalışın ve herhangi bir öngörü alıp almadığınızı görün.
- Üçüncü tarafların iyi analizörler yazmasını kolaylaştırın
Roslyn'de Microsoft'ta çalıştıktan sonra Coverity'de çalıştım ve yaptığım şeylerden biri Roslyn'i kullanarak analizörün ön ucunu almaktı. Microsoft tarafından sağlanan doğru bir sözcüksel, sözdizimsel ve anlambilimsel çözümleme yaparak, ortak çok iş parçacıklı sorunlar bulan dedektör yazma çalışmalarına yoğunlaşabiliriz.
- Soyutlama seviyesini yükseltin
Irklar, çıkmazlar ve tüm bu şeylere sahip olmamızın temel bir nedeni , ne yapacağımızı söyleyen programlar yazmamızdır ve hepimizin zorunlu programlar yazarken saçmalık olduğumuzdur; bilgisayar söylediklerinizi yapar ve biz de yanlış şeyleri yapmasını söyleriz. Birçok modern programlama dili, bildirimsel programlama hakkında gittikçe daha fazladır: istediğiniz sonuçları söyleyin ve derleyicinin bu sonuca ulaşmak için etkili, güvenli ve doğru yolu bulmasına izin verin. Yine, LINQ düşünün; söylemenizi istiyoruz from c in customers select c.FirstName, ki bu bir niyeti ifade ediyor . Derleyicinin kodu nasıl yazacağını bulmasına izin verin.
- Bilgisayar sorunlarını çözmek için bilgisayar kullanın.
Makine öğrenme algoritmaları bazı görevlerde elle kodlanmış algoritmalardan çok daha iyidir, ancak elbette doğruluk, eğitim için harcanan zaman, kötü eğitimin getirdiği önyargılar vb. Ancak şu anda "elle" kodladığımız pek çok görevin yakında makine tarafından üretilen çözümlere uygun olması muhtemeldir. İnsanlar kodu yazmıyorlarsa, hata yazmıyorlar.
Üzgünüm, orada biraz dolaşıyordu; bu çok büyük ve zor bir konu ve bu sorun alanındaki ilerlemeyi takip ettiğim 20 yıldır PL topluluğunda net bir fikir birliği oluşmadı.