[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
- From: "Alexander Terekhov" <terekhov web de>
- To: phil-list redhat com
- Subject: RE: [PATCH 2.5.64] Real-time futexes (priority inheritance/protec tion/robust support) take 4
- Date: Wed, 26 Mar 2003 22:49:29 +0100
"Perez-Gonzalez, Inaky" schrieb am 25.03.03 00:54:05:
[...]
> I reached the conclusion that you can only hold more than
> one pp mutexes only if they have the same prio ceiling,
Uhmm, "only if they have the same prio ceiling"...
Given: three threads A > B > C [priority wise] and two PP
locks L1 and L2. The locks are used as follows:
thread A: L1
thread B: L2
thread C: L2, L1 [nested].
The assigned ceilings are:
L1: prty(A)
L2: prty(B)
To me, this looks just fine. Note that if thread C would
have "L1, L2" locking order, then according to my reading
of the standard, the L2-ceiling would have to be raised to
prty(A) (otherwise, implementation would fail with EINVAL
on an attempt to lock L2). Or am I just missing and/or
misunderstanding something?
> and also that the priority boosts you can get can only
> be up to the priority ceiling.
I'd rather "don't care" and "allow" it to fail with EINVAL
on an attempt to lock a PP mutex if thread's {"effective"}
priority is higher than the mutex's ceiling. Oder?
regards,
alexander.
______________________________________________________________________________
Erster Klick - SMS versenden, zweiter Klick - die Telefonnummer im
Adressbuch speichern bei: http://freemail.web.de/features/?mc=021151
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]