RE: [PATCH 2.5.64] Real-time futexes (priority inheritance/protec tion/robust support) take 4
"Alexander Terekhov" <[email protected]>
| Newsgroups | gmane.comp.lib.phil |
|---|---|
| Organization | http://freemail.web.de/ |
| Message-ID | <[email protected]> |
"Perez-Gonzalez, Inaky" schrieb am 26.03.03 21:08:05: [...] > What I meant was that for the cond->__data.__lock and the "mutex" > argument, we can use rtfutex. I think that internally, "realtime" condvars still can use the "least expensive" locks (apart from optional "debugging features", of course) that just need to ensure priority ordered wakeup only (no need for PI and/or PP with respect to internal loking). I think so because the standard says: <quote> The pthread_cond_broadcast() or pthread_cond_signal() functions may be called by a thread whether or not it currently owns the mutex that threads calling pthread_cond_wait() or pthread_cond_timedwait() have associated with the condition variable during their waits; however, if predictable scheduling behavior is required, then that mutex shall be locked by the thread calling pthread_cond_broadcast() or pthread_cond_signal() </quote>. To me, that seems to mean that realtime applications would have to (intended behavior, I mean) perform the CV-signaling under the "protection" (PI/PP) of CV- associated/dynamically-bound mutex at the signaling places where the unbounded-priority-inversion problem can arise. Oder? regards, alexander. ______________________________________________________________________________ Schon wieder Viren-Alarm? Bei WEB.DE FreeMail ist das kein Problem, hier ist der Virencheck inklusive! http://freemail.web.de/features/?mc=021158