RE: [PATCH 2.5.64] Real-time futexes (priority inheritance/protec tion/robust support) take 4

["Alexander Terekhov" <terekhov web de>]

"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