"Fix wrong clock source in mutex" broke fio for me

With the latest fio git tree, I get:

fio: job startup hung? exiting.

on startup, and it looks like the latest commit, 69a852f5 ("Fix wrong clock source in mutex") breaks things for me (Ubuntu 9.10 beta). My system seems to use CLOCK_REALTIME for pthread_cond_timedwait() by default.

The cleanest solution seems to be to explicitly set which clock to use in pthread_cond_timedwait() via pthread_condattr_setclock() when initializing the condition variable, although I'm not sure how portable this is away from modern Linux (ie do all platforms that fio cares about have pthread_condattr_setclock()?).

---
 mutex.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

index 9f0f094..34b3324 100644
@@ -72,6 +72,7 @@ struct fio_mutex *fio_mutex_init(int value)
 
 	pthread_condattr_init(&cond);
 	pthread_condattr_setpshared(&cond, mflag);
+	pthread_condattr_setclock(&cond, CLOCK_MONOTONIC);
 	pthread_cond_init(&mutex->cond, &cond);
 
 	ret = pthread_mutex_init(&mutex->lock, &attr);

Woops, how did I miss that?

I did a quick check, and at least newer revisions have it. Hmm I'm a bit torn on this, perhaps the safer option is just to revert the bad commit.

OK, what I'll do is apply this and then we can worry about older platforms later. I usually try and test FreeBSD and Solaris occasionally, to ensure that full releases at least work.

Thanks for reporting and fixing this, Roland!

Jens Axboe

But presumably you made that commit because it fixed some platform?

The default clock for pthread_cond_timedwait() seems poorly specified, I'm not able to find any definitive statement about what it uses, and pthread_condattr_setclock() seems to be option in the pthreads spec. Seems to be a mess.

Anyway not sure what the best idea is....

- R.

I agree, in any case it's a lot more sane to specifically set the used clock source. So lets just keep it as-is, if there's any fall out later I'll deal with it.

Jens Axboe