Messages in this thread | | | From | "David Schwartz" <> | Subject | RE: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow) | Date | Wed, 25 Jan 2006 18:05:47 -0800 |
| |
> Kaz's post clearly interprets the POSIX spec differently from you. The > policy can decide *which of the waiting threads* gets the mutex, but the > releasing thread is totally out of the picture. For good or bad, the > current pthread_mutex_unlock() is not POSIX-compliant. Now then, if > we're forced to live with that, for efficiency's sake, that's OK, > assuming that valid workarounds exist, such as inserting a sched_yield() > after the unlock.
My thanks to David Hopwood for providing me with the definitive refutation of this position. The response is that the as-if rules allows the implementation to violate the specification internally provided no compliant application could tell the difference.
When you call 'pthread_mutex_lock', there is no guarantee regarding how long it will or might take until you are actually waiting for the mutex. So no conforming application can ever tell whether or not it is waiting for the mutex or about to wait for the mutex.
So you cannot write an application that can tell the difference.
His exact quote is, "It could have been the case that the other threads ran more slowly, so that they didn't reach the point of blocking on the mutex before the pthread_mutex_unlock()."
You can find it on comp.programming.threads if you like.
DS
- 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/
| |