Message-ID: <41A2902A.5050308@timesys.com>
Date: Mon, 22 Nov 2004 20:19:38 -0500
From: john cooper <john.cooper@timesys.com>
User-Agent: Mozilla Thunderbird 0.8 (X11/20040913)
MIME-Version: 1.0
To: Ingo Molnar <mingo@elte.hu>
CC: "Bill Huey (hui)" <bhuey@lnxw.com>, Esben Nielsen <simlo@phys.au.dk>,
       linux-kernel@vger.kernel.org, john cooper <john.cooper@timesys.com>
Subject: Re: Priority Inheritance Test (Real-Time Preemption)
References: <Pine.OSF.4.05.10411212107240.29110-100000@da410.ifa.au.dk> <20041122092302.GA7210@nietzsche.lynx.com> <41A1F4B2.10401@timesys.com> <20041122152452.GA2036@elte.hu>
In-Reply-To: <20041122152452.GA2036@elte.hu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1694
Lines: 48

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/