lkml.org 
[lkml]   [2004]   [Oct]   [22]   [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
Scott Wood wrote:

>On Thu, Oct 21, 2004 at 02:09:19PM -0400, john cooper wrote:
>
>>That's true for the case where the current priority is
>>somewhere else handy (likely) and we don't need to traverse
>>the list for other reasons such as allowing/disallowing
>>recursive acquisition of a mutex by a given task.
>>
>
>How would maintaining priority order make it faster to check for
>recursive usage?
>
It wouldn't. My point was an exhaustive traversal may be
needed for other reasons with an insertion sort being
near free.

Yet considering the cost to maintain these lists in priority
order with multiple spinlock acquisition sequences due to how
the aggregate data structure must be traversed/ordered,
I haven't yet convinced myself either way.

>On uniprocessor, one may wish to turn rwlocks into recursive non-rw
>mutexes, where recursion checking would use a single owner field.
>
It isn't obvious to me how this would address the case of a
task holding a reader lock on mx-A then blocking on mx-B.
Another task attempting to acquire a reader lock on mx-A would
block rather than immediately acquiring the lock.

-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.507 / U:0.484 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site