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

[linux]

> 	It can tell the difference between the other thread getting
> the mutex first and it getting the mutex first. But it cannot tell the
> difference between an implementation that puts random sleeps before calls
> to 'pthread_mutex_lock' and an implementation that has the allegedly
> non-compliant behavior. That makes the behavior compliant under the
> 'as-if' rule.
> 
> 	If you don't believe me, try to write a program that prints
> 'non-compliant' on a system that has the alleged non-compliance but is
> guaranteed not to do so on any compliant system. It cannot be done.
> 
> 	In order to claim the alleged compliance, you would have to
> know that a thread waiting for a mutex did not get it. But there is no
> possible way you can know that another thread is waiting for the mutex
> (as opposed to being about to wait for it). So you can never detect the
> claimed non-compliance, so it's not non-compliance.

An excellent point, but the existence of pthread_mutex_trylock()
invalidates it.

To be very specific, the following will do the job:

volatile unsigned shared_variable;
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;

void
thread_function()
{
	unsigned prev_value = shared_variable;

	for (;;) {
		unsigned cur_value, delta;
		if (pthread_mutex_trylock(&lock) == 0) {
			cur_value = ++shared_variable;
			pthread_mutex_unlock(&lock);
			delta = cur_value - prev_value;
		} else {
			/* Another thread is holding the lock. */
			pthread_mutex_lock(&lock);
			cur_value = ++shared_variable;
			pthread_mutex_unlock(&lock);
			delta = cur_value - prev_value;
			if (delta == 1)
				fatal("non-compliant");
		}
		/* Assuming we don't wrap */
		if (delta == 0)
			fatal("buggy as a roach motel");
	}
}

You need to run more than one instance of the thread_function()
to have a chance of triggering the non-compliant message, of course.
-
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/