[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



> -----Original Message-----
> From: Alexander Terekhov [mailto:terekhov web de]
> 
> "Perez-Gonzalez, Inaky" <inaky perez-gonzalez intel com> schrieb am
> 25.03.03 00:46:25:
> [...]
> > On condvars, I am not that sure - but to me it looks like they can use
> the
> > same mechanism as mutexes. It even makes sense to enable PI/PP/robust.
> 
> I'm not sure that I'm not just missing and/or misunderstanding
> something...

I think I didn't explain correctly what I meant (on second reading...) - I
meant that the mutex mechanism in the condvar can perfectly use rtfutex,
because there are no fundamental modifications to the actual mutex behavior
[or it looks like that by looking at the NPTL source code] - now, after
looking again at pthread_cond_timedwait.c, I think I know what you mean.

What I meant was that for the cond->__data.__lock and the "mutex" argument,
we can use rtfutex. The "futex" (&cond->__data.__wakeup_seq) seems to be
using futexes in a similar fashion to that of the barriers (for example).
This one cannot use rtfutex, but can keep doing futex with no problem.

So, the idea is not that the condvars get an overhaul - is that where
rtfutex can be used, well, it can be used. I agree there is no way to do
deadlock detection on the general condvar predicate itself, as there is no
ownership - that's the very reason why rtfutexes don't apply here.

> aside). Well, a rather interesting problem to solve is the implementation
> of
> a "realtime" condition variable that would handle futex overflows. Uhmm,
> for
> example, the one that I've tried to come up (just as a sort of "academic
> exercise"): http://www.terekhov.de/DESIGN-futex-CV.txt,
> http://www.terekhov.de/DESIGN-futex-CV.cpp,
> http://www.terekhov.de/DESIGN-futex-CV-with-async.cancelable-wait.txt)
> does
> NOT ensure priority ordered wakeup when the futex value has reached "end-
> of-
> cycle" (and until it gets reset by the last "old" waiter).

Let me find some time to go over these - sounds rather interesting,

Thanks,

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]