Sahte uyandırmaların açıklaması, düzeltmeye değmeyecek bir hataya benziyor, doğru mu?


30

Sahte Uyanmalar hakkındaki Wikipedia makalesine göre

msgstr "durum değişkeni belirtilmese bile, bir iplik bekleme durumundan uyanabilir".

Bu 'özellik' hakkında bir şey bilsem de, aynı makalede şu ana kadar neyin neden olduğunu asla bilemedim.

"Sahte uyanmalar kulağa garip gelebilir, ancak bazı çok işlemcili sistemlerde koşulu uyandırmayı tamamen öngörülebilir hale getirmek, tüm koşul değişken işlemlerini önemli ölçüde yavaşlatabilir."

Onarmaya değmeyecek bir böcek gibi geliyor, doğru mu?


1
ile ilgili: "Neden pthread_cond_wait sahte uyandırmalara sahip?", stackoverflow.com/questions/8594591/…
Florian Castellane

Yanıtlar:


39

TL; Sahte uyanmaların DR varsayımı ("sözleşmesi"), iplik geçirme makinesinin gerçekçi bir şekilde uygulanmasına izin vermek için verilen makul bir mimari karardır.

Burada “performansla ilgili hususlar” önemsizdir, bunlar yayınlanmış bir yetkili referansta belirtildiği için yaygınlaşan yanlış anlaşılmalardır. - (sadece sormak yetkili referanslar bilirsin, hatalar olabilir Galileo Galilei ) Wikipedia makalesi mükemmel yayınlanan Atıf yapma onların biçimsel kurallara uygunluğunu çünkü sadece alıntı nota atıfta tutar.

Sahte uyanma kavramını tanıtmak için çok daha zorlayıcı bir sebep, SO'da bu cevabın, bu makalenin (eski versiyonunda) sunulan ek ayrıntılara dayanan cevabı verilmiştir:

Sahte uyanmalarla ilgili Wikipedia makalesinde şu hata mesajı var:

pthread_cond_wait()Linux fonksiyon kullanılarak uygulanır futexsistem çağrısı. Linux'taki her engelleme sistemi çağrısı EINTR, işlem bir sinyal aldığında aniden geri döner . ... pthread_cond_wait()beklemeyi yeniden başlatamaz, çünkü futexsistem çağrısı dışında olduğu zamanlar içinde gerçek bir uyanışı kaçırabilir ...

Sadece bir düşünün ... herhangi bir kod gibi, iş parçacığı zamanlayıcısı, donanım / yazılımdaki anormal bir olay nedeniyle geçici olarak karartma yaşayabilir. Elbette, bunun mümkün olduğu kadar nadir olmasına özen gösterilmelidir, ancak% 100 sağlam yazılım diye bir şey olmadığından, bunun olabileceğini varsaymak ve programcının bunu tespit etmesi durumunda zarif toparlanmaya dikkat etmek makul olacaktır (örn. eksik kalp atışlarını gözlemleyerek ).

Şimdi, karartıcı sırasında bekleyen konuları bildirmek için bazı sinyalleri kaçırabileceğini göz önünde bulundurarak zamanlayıcı nasıl iyileşebilir? Zamanlayıcı hiçbir şey yapmazsa, "şanssız" dişler sonsuza dek bekleyecek şekilde sadece askıda kalacaktır - bundan kaçınmak için zamanlayıcı sadece tüm bekleyen dişlilere bir sinyal gönderir.

Bu, bekleyen iş parçacığının bir sebep olmadan bildirilebileceği bir “sözleşme” oluşturulmasını gerekli kılar. Kesin olarak, bir sebep olurdu - zamanlayıcı karartması - ama iş parçacığı (iyi bir nedenle) zamanlayıcı iç uygulama ayrıntılarına uymayacak şekilde tasarlandığından, bu nedenin "sahte" olarak sunulması daha iyi olur.


İplik perspektifinden bakıldığında, bu biraz Postel yasasına benziyor (diğer bir deyişle sağlamlık ilkesi ),

Yaptıklarınızda muhafazakar olun, Diğerlerinden kabul ettiğiniz şeyler konusunda liberal olun.

Sahte uyandırmaların varsayımı, ipliği ne olduğu konusunda muhafazakar olmaya zorlar : diğer konuları bildirirken durumu ayarlayın ve kabul ettiği şekilde liberal : beklemeden geri dönüş durumunda durumu kontrol edin ve henüz gelmediyse bekleyin.


10
Ugh ... Postel kanunu ... HTML'nin ve her türlü web teknolojisinin bu kadar fazla saçılmasının sebebi (örneğin, kötü etiket yerleştirmenin HTML kabulü). Bu bir yana, iyi cevap.
Thomas Eding

3
Postel'in yasası neden birçok hatanın yıllarca yakalanmamasıdır, çünkü fonksiyonunuz yanlış çıktı verse bile, uygulama hala çalışıyor gibi görünüyor! Şimdiye kadarki en iyi buluş.
Pacerier

2
@Pacerier: yanlış çıktı veren işlev Postel yasasını (muhafazakar kısım) takip etmiyor.
YvesgereY

@Pacerier: OTOH, diğer bileşenlerin sıkı olmasını ve böylelikle böceklerin daha erken yakalanmasını talep etmek, 'Fail Fast' ilkesi ve 'Contract Based' tasarımı tarafında ortaya çıkan ilginç bir durumdur.
YvesgereY

1

Arayan kodun yarış koşullarıyla başa çıkmak için aynı işlemi (durumu kontrol etmek) kullanması gerektiğinden sabitlemeye değmez.

Aşağıdakilerle özetlediğim iki konu için tek bir muamele:

Sahte uyandırma: bekleyen iş parçacığı koşul kurulmadan önce zamanlanır.
Zorla uyuyakalmak: bekleme ipliği, durum tekrar tahrif edildikten sonra programlanır.

Daha sonra olabileceğinden, bazıları sözleşmede sahte uyandırma yapmak kadar ileri gitti:

  • Tahmini döngüler gerektirerek iyi uygulamaları zorlamak.
  • Zamanlayıcı uygulaması için bazı özgürlükler verilmesi (@gnat'ın işaret ettiği gibi acil durum kurtarma seçeneği dahil).

SO referansı


Bunu + 1'lemek isterdim, ancak arayanların zorla uyuyakalmaları ele almak için kestirici döngüler eklemesi için kasıtlı olarak sahte uyandırmalar başlattığı fikri. Bunu düşünülemez buluyorum.
ruakh

“Amaç, doğrulayıcı döngüler gerektirerek doğru / sağlam kodu zorlamaktı.” Verilen bağlantıya bakınız.
YvesgereY
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.