lkml.org 
[lkml]   [2004]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
Eugeny S. Mints wrote:

> john cooper wrote:
>
>> A task holding several mutexes shouldn't be an issue.
>> Though per task an ownership list needs to be maintained
>> in descending priority order such that the effective PI
>> can be resolved from all task owned mutexes.
>
>
> Seems it is too coplex model at least for the first step. The one of
> possible trade-offs coming on mind is to trace the number of resources
> (mutexes) held by a process and to restore original priority only when
> resource count reaches 0. This is one of the sollutions accepted by
> RTOS guys.

It would seem a mutex ownership list still needs to be maintained.
Doing so in unordered priority will give a small fixed insertion
time, but will require an exhaustive search in order to calculate
maximum priority. Doing so in priority order will require an
average of #mutex_owned / 2 for the insertion, and gives a fixed
time for maximum priority calculation. The latter appears to offer
a performance benefit to the degree the incoming priorities are
random.

> The other concern with PI is that most likely PI should be prohibited
> for utilization with locks which are used in the way similar to
> "waiting completition" - i.e. if PI is employed on a mutex it is
> prohibited to release it if a process is not the owner of the mutex.

Yes, that type of usage breaks the notion of ownership.
It would be a error for a task to attempt relinquishing
a mutex which it had not acquired and was holding at the
time of unlock.

>> http://developer.osdl.org/dev/robustmutexes
>
>
> It is definitly non-trivial work to adapt this approach - there are a
> lot of issues.

I should have qualified that reference. Those folks are
addressing more than PI mutexes. Indeed their goal is
support of fast user mutexes which offer detection of mutex
owners gone astray (exited, killed, etc..). It is the kernel
component of the work to which I was referring.

-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/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.605 / U:6.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site