lkml.org 
[lkml]   [2006]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow)
Nick Piggin wrote:
> Howard Chu wrote:
>
>>> Another reason might be because we will be running for a very long
>>> time without requiring the lock.
>>
>>
>> And again in this case, A should not be immediately reacquiring the
>> lock if it doesn't actually need it.
>>
>
> No, not immediately, I said "for a very long time". As in: A does not
> need the exclusion provided by the lock for a very long time so it
> drops it to avoid needless contention, then reaquires it when it finally
> does need the lock.

OK. I think this is really a separate situation. Just to recap: A takes
lock, does some work, releases lock, a very long time passes, then A
takes the lock again. In the "time passes" part, that mutex could be
locked and unlocked any number of times by other threads and A won't
know or care. Particularly on an SMP machine, other threads that were
blocked on that mutex could do useful work in the interim without
impacting A's progress at all. So here, when A leaves the mutex unlocked
for a long time, it's desirable to give the mutex to one of the waiters
ASAP.

>>> Or we might like to release it because
>>> we expect a higher priority process to take it.
>>
>>
>> And in this case, the expected behavior is the same as I've been
>> pursuing.
>>
>
> No, we're talking about what happens when A tries to aquire it again.
>
> Just accept that my described scenario is legitimate then consider it in
> isolation rather than getting caught up in the superfluous details of how
> such a situation might come about.

OK. I'm not trying to be difficult here. In much of life, context is
everything; very little can be understood in isolation.

Back to the scenario:

> A realtime system with tasks A and B, A has an RT scheduling priority of
> 1, and B is 2. A and B are both runnable, so A is running. A takes a
> mutex
> then sleeps, B runs and ends up blocked on the mutex. A wakes up and at
> some point it drops the mutex and then tries to take it again.
>
> What happens?

As I understand the spec, A must block because B has acquired the mutex.
Once again, the SUS discussion of priority inheritance would never need
to have been written if this were not the case:

>>>
In a priority-driven environment, a direct use of traditional primitives
like mutexes and condition variables can lead to unbounded priority
inversion, where a higher priority thread can be blocked by a lower
priority thread, or set of threads, for an unbounded duration of time.
As a result, it becomes impossible to guarantee thread deadlines.
Priority inversion can be bounded and minimized by the use of priority
inheritance protocols. This allows thread deadlines to be guaranteed
even in the presence of synchronization requirements.
<<<

The very first sentence indicates that a higher priority thread can be
blocked by a lower priority thread. If your interpretation of the spec
were correct, then such an instance would never occur. Since your
scenario is using realtime threads, then we can assume that the Priority
Ceiling feature is present and you can use it if needed. (
http://www.opengroup.org/onlinepubs/000095399/xrat/xsh_chap02.html#tag_03_02_09_06
Realtime Threads option group )

--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/

-
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: 2006-01-27 09:10    [W:0.138 / U:3.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site