Helge Hafting wrote:
David Schwartz wrote:
nothing says that it can't call pthread_mutex_lock and re-acquire the
mutex
before any other thread gets around to getting it.
Wrong.
The spec says that the mutex must be given to a waiter (if any) at the
moment of release.
Repeating myself here...
To me it says that the scheduling policy decides at the moment of release.
What if the scheduling policy decides *right then* to give the mutex to
the next running thread that tries to aquire it?
That would be the logical way for a scheduling policy to decide the next
owner of the mutex.
--
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]
