lkml.org 
[lkml]   [2006]   [Jan]   [25]   [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:
>> The SUSv3 text seems pretty clear. It says "WHEN
>> pthread_mutex_unlock() is called, ... the scheduling policy SHALL
>> decide ..." It doesn't say MAY, and it doesn't say "some undefined
>> time after the call." There is nothing optional or
>> implementation-defined here. The only thing that is not explicitly
>> stated is what happens when there are no waiting threads; in that
>> case obviously the running thread can continue running.
>>
>
> But it doesn't say the unlocking thread must yield to the new mutex
> owner, only that the scheduling policy shall determine the which
> thread aquires the lock.

True, the unlocking thread doesn't have to yield to the new mutex owner
as a direct consequence of the unlock. But logically, if the unlocking
thread subsequently calls mutex_lock, it must block, because some other
thread has already been assigned ownership of the mutex.

> It doesn't say that decision must be made immediately, either (eg.
> it could be made as a by product of which contender is chosen to run
> next).

A straightforward reading of the language here says the decision happens
"when pthread_mutex_unlock() is called" and not at any later time. There
is nothing here to support your interpretation.
>
> I think the intention of the wording is that for deterministic policies,
> it is clear that the waiting threads are actually worken and reevaluated
> for scheduling. In the case of SCHED_OTHER, it means basically nothing,
> considering the scheduling policy is arbitrary.
>
Clearly the point is that one of the waiting threads is waken and gets
the mutex, and it doesn't matter which thread is chosen. I.e., whatever
thread the scheduling policy chooses. The fact that SCHED_OTHER can
choose arbitrarily is immaterial, it still can only choose one of the
waiting threads.

The fact that SCHED_OTHER's scheduling behavior is undefined is not free
license to implement whatever you want. Scheduling policies are an
optional feature; the basic thread behavior must still be consistent
even on systems that don't implement scheduling policies.

--
-- 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-25 20:38    [W:0.114 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site