Gerçek zamanlı öncelikli işlem yürütmenin olumsuzlukları?

Gerçek zamanlı önceliğe ( chrt -f 99) sahip çalışan işlemlerin olumsuz yönleri var mı?

Benim hipotezim, bunun bir yakınlıkla birleştirilmesinin, süreçlerimin herhangi bir ön değerlendirmesinin minimum olmasını sağlayacak ve bu nedenle herhangi bir titreşimin (özellikle ağ gecikmesi) en aza indirileceği - bu genel gecikme ile yardımcı olmayacak, ancak şu anda daha fazla titreme ile ilgili.

(Çekirdek: 2.6.16 / 3.0)

Gerçek zamanlı bir işlem yürütmenin en büyük dezavantajı, işlemin sistemdeki diğer tüm işlemleri kolayca aç bırakabilmesidir. Sizin bakış açınızdan sonuç, gerçek zamanlı işlem CPU'yu kullandığı sürece bilgisayarın klavyeye, fareye ve muhtemelen ağa tamamen yanıt vermemesi olacaktır. Bu, bir şeyler ters giderse ve süreç sonsuz bir döngüye girerse veya süreç periyodik olarak girişi beklemeden uzun süren bir hesaplamaya başlarsa bile olabilir. (Örneğin, SETI @ home'u gerçek zamanlı öncelikle çalıştırmayın.)

Çok çekirdekli bir CPU üzerinde yalnız tek iş parçacıklı bir işlemin bu soruna neden olma olasılığı daha düşüktür, çünkü daha düşük öncelikli işlemin kullanabileceği başka çekirdekler vardır. Ancak bu süreç herhangi bir alt süreç oluşturuyorsa, aynı gerçek zamanlı önceliği devralırlar, böylece dikkatli olmazsanız işler kontrolden çıkabilir.

sched_setscheduler(2)Adam sayfa iyi tavsiyesi var:

SCHED_FIFO veya SCHED_RR altında planlanan bir süreçte engellenmeyen sonsuz döngü sonsuza kadar daha düşük önceliğe sahip tüm işlemleri engelleyeceğinden, bir yazılım geliştiricisi konsolda her zaman test edilen uygulamadan daha yüksek statik öncelik altında planlanan bir kabuk bulundurmalıdır. Bu, beklendiği gibi engellenmeyen veya sona ermeyen test edilmiş gerçek zamanlı uygulamaların acil olarak öldürülmesine izin verecektir. Ayrıca getrlimit (2) 'deki RLIMIT_RTTIME kaynak sınırının açıklamasına bakın.

Tüm X gerçek zamanlı önceliğini vermek istemiyorsanız, bu konsolda bir kabuk olmalıdır - Xterm altında değil.