Messages in this thread | | | Subject | Re: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow) | From | Lee Revell <> | Date | Wed, 25 Jan 2006 20:04:15 -0500 |
| |
On Wed, 2006-01-25 at 16:49 -0800, Howard Chu wrote: > Basic "fairness" isn't the issue. Fairness is concerned with which of > *multiple waiting threads* gets the mutex, and that is certainly > irrelevant here. The issue is that the releasing thread should not be > a candidate. >
You seem to be making 2 controversial assertions:
1. pthread_mutex_unlock must cause an immediate reschedule if other threads are blocked on the mutex, and 2. if the unlocking thread immediately tries to relock the mutex, another thread must get it first
I disagree with #1, which makes #2 irrelevant. It would lead to obviously incorrect behavior, pthread_mutex_unlock would no longer be an RT safe operation for example.
Also consider a SCHED_FIFO policy - static priorities and the scheduler always runs the highest priority runnable thread - under your interpretation of POSIX a high priority thread unlocking a mutex would require the scheduler to run a lower priority thread which violates SCHED_FIFO semantics.
Lee
- 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/
| |