Andriy Gapon wrote:
Maybe. But that's not what I see with my small example program. One
thread releases and re-acquires a mutex 10 times in a row while the
other doesn't get it a single time.
I think that there is a very slim chance of a blocked thread
preempting a running thread in this circumstances. Especially if
execution time between unlock and re-lock is very small.
It does not depends on how many times your thread acquires or
re-acquires mutex, or
how small the region the mutex is protecting. as long as current thread
runs too long,
other threads will have higher priorities and the ownership definitely
will be transfered,
though there will be some extra context switchings.
I'd rather prefer to have an option to have FIFO fairness in mutex
lock rather than always avoiding context switch at all costs and
depending on scheduler to eventually do priority magic.
It is better to implement this behavior in your application code, if it
is implemented in thread library, you still can not control how many
times acquiring and re-acquiring can be allowed for a thread without
context switching, a simple FIFO as you said here will cause dreadful
performance problem.
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
