Re: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Howard Chu wrote:
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.


OK, so what happens if my scheduling policy decides _right then_, that
the next _running_ thread that was being blocked on or tries to aquire
the mutex, is the next owner?

This is the logical way for a *scheduling* policy to determine which
thread gets the mutex. I don't know any other way that the scheduling
policy could determine the next thread to get the mutex.


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.


I don't know that it exactly says one of the waiting threads must get the
mutex.

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.


It just so happens that normal tasks in Linux run in SCHED_OTHER. It
is irrelevant whether it might be an optional feature or not.

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux