![]() | |||||||||||||
Messages in this thread |
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 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-26 10:03 [from the cache] ©2003-2008 | |||||||||||||