Çoğu muteks uygulaması neden adil değil?

Anladığım kadarıyla, bir muteksin en popüler uygulamalarının (örn. C ++ 'da std :: mutex) adaleti garanti etmediği - yani, çekişme durumlarında, kilidin iş parçacıkları tarafından sırayla alınacağını garanti etmezler. lock () olarak adlandırılır. Aslında, yüksek çekişme durumlarında, muteksi elde etmeyi bekleyen ipliklerden bazılarının asla elde edemeyeceği (umarım nadir de olsa) bile mümkündür .

Bu benim için yararsız bir davranış gibi görünüyor - bana göre adil bir muteks bir programcının istediği / beklediği şeyle daha uyumlu davranışlar üretecek.

Mutekslerin tipik olarak adil olmak için neden uygulanmadığının nedeni "performans" tır, ancak bunun ne anlama geldiğini daha iyi anlamak istiyorum - özellikle, muteksin adalet gereksinimini rahatlatmak performansı nasıl geliştirir? Bu "adil" bir muteks uygulamak için önemsiz gibi görünüyor - sadece uyku (iş parçacığını uykuya koymadan önce mutex'in bağlı listesinin kuyruğuna kilitlemek () ekleyin ve sonra unlock () aynı listenin başı ve uyan.

Burada hangi muteks-uygulama anlayışı eksik, bu daha iyi performans için adaletten fedakarlık etmenin neden değerli olduğunu açıklar?

Jim Sawyer'ın cevabı bir yanıta işaret ediyor: Farklı önceliklere sahip iplikleriniz varsa, "adil" davranış yanlış olur. Çalışabilecek birden çok iş parçacığınız varsa, en yüksek öncelikli iş parçacığı genellikle çalışması gereken iş parçacığıdır.

Ancak, bilmeniz gereken işletim sistemi uygulamasının biraz tartışılan bir sırrı vardır, bu da bazen işletim sistemlerinin bir kullanıcı iş parçacığını ele geçirerek kullanıcı olarak kod çalıştırmasıdır. Güvenlik nedeniyle, bunu yapan çoğu işletim sistemi bunu yalnızca bir iş parçacığı engellendiğinde yapar. İşletim sistemi tamamlandığında, iş parçacığı yeniden askıya alınır ve bu genellikle iş parçacığını bekleme kuyruğunun arkasına taşıma etkisine sahiptir.

Tipik bir örnek, Unix'te bir sinyal işleyici, VMS'de bir asenkron sistem tuzağı veya Windows NT'de bir asenkron prosedür çağrısıdır. Bunların hepsi aynı şeydir: İşletim sistemi, bir olayın gerçekleştiğini kullanıcı sürecine bildirmelidir ve bu, kullanıcı alanında kod çalıştırılarak ele alınır.

Asenkron G / Ç gibi birçok işletim sistemi hizmeti genellikle bu tesisin üzerine uygulanır.

Başka bir örnek, işlemin bir hata ayıklayıcının kontrolü altında olması. Bu durumda, hata ayıklama sistemi çeşitli nedenlerle kodu kullanıcı görevi olarak yürütebilir.

'Önceliklerin ters çevrilmesi', adaletin arzu edilmemesinin bir nedenidir. Düşük öncelikli bir işlem kilitli mutekse çarpar ve uyur. Sonra daha yüksek öncelikli bir süreç buna çarpar ve uyur. Muteks kilidini açtığında, bir sonraki kilit hangi işlemi almalıdır?

Adil bir muteks, ömrünün çoğunu haksız bir muteksten daha fazla kilitli geçirir, diğer her şey eşittir. Çünkü haksız bir muteksi serbest bırakan bir iş parçacığı her zaman kilidini açabilir. Ancak adil bir muteksi serbest bırakan bir iş parçacığı ancak garson sırası boş olduğunda kilidini açabilir. Aksi takdirde, serbest bırakma ipliği, bir sonraki iş parçacığının uğruna muteksi kilitli bırakmalıdır, yani garson kuyruğundaki ilk iş parçacığı, daha sonra ayıklanıp uyandırılır. Muteks en azından yeni uyandırılan iş parçacığı bir CPU'da zamanlanana kadar kilitli kalır, bu da şu anda çalıştırılabilen çok sayıda iş parçacığı varsa uzun sürebilir.

Ve serbest bırakma ipliği derhal aynı muteksi tekrar elde etmeye çalışırsa, kendini garson kuyruğunun arkasına koymalı ve uyumaya başlamalıdır. Eğer iplik başlamak için muteksi serbest bırakmasaydı bu olmazdı. Bu nedenle bu daha uzun "daha açgözlü" kritik bölümleri teşvik eder.