I actually used sched_yield for the 'inverse' mutex case. One thread was
pretty much exclusively holding a mutex, but other threads sometimes try
to get through the same critical section and block on mutex_lock.
The first thread then occasionally does,
mutex_unlock()
sched_yield()
mutex_lock()
Without the sched_yield, other threads never get a chance to wake up and
grab the mutex before the mutex hogging thread is back in the critical
section.
This is ofcourse the simple explanation, this was actually part of a
wrapper around pthreads that needed to provide non-concurrent
co-routines that in specific situations could run concurrently for a bit
to do DNS lookups and such.
Not sure how different semantics affect this because I went with a
different solution a while ago.
Jan
-
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/