Re: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow)
From: Howard Chu
Date: Wed Jan 25 2006 - 14:34:32 EST
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/