Messages in this thread | | | Date | Mon, 22 Nov 2004 20:19:38 -0500 | From | john cooper <> | Subject | Re: Priority Inheritance Test (Real-Time Preemption) |
| |
Ingo Molnar wrote: > * john cooper <john.cooper@timesys.com> wrote: > > >>I'd hazard a guess the reason existing implementations do not do this >>type of dependency-chain closure is the complexity of a general >>approach. [...] > > > please take a look at the latest patch, it is i believe handling all the > cases correctly. It certainly appears to solve the cases uncovered by > pi_test.
Yes I see where you are walking the dependency chain in pi_setprio(). But this is under the global spinlock 'pi_lock'.
My earlier comment was of the difficulty to establish fine grained locking, ie: per-mutex to synchronize mutex ownership/waiter lists and per task to synchronize the list maintaining mutexes owned by task. While this arguably scales better in an SMP environment, there are issues of mutex traversal sequence during PI which lead to deadlock scenarios. Though I believe there are reasonable constraints placed on application mutex acquisition order which side step this problem.
In the current design pi_lock has scope protecting all mutex waiter lists (rooted either in mutex or owning task), as well as per-mutex owner(s). The result of this is pi_lock must be speculatively acquired before altering any of the above lists/data regardless whether a PI scenario is encountered. The behavior looks correct to my reading. However I'd offer there is more concurrency possible in this design.
-john
-- john.cooper@timesys.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |