Messages in this thread | | | Date | Fri, 27 Jan 2006 09:24:45 +1100 | From | Nick Piggin <> | Subject | Re: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow) |
| |
Howard Chu wrote: > Nick Piggin wrote:
>> Regardless of why, that is just the simplest scenario I could think >> of that would give us a test case. However... >> >> Why not hold onto it? We sometimes do this in the kernel if we need >> to take a lock that is incompatible with the lock already being held, >> or if we discover we need to take a mutex which nests outside our >> currently held lock in other paths. Ie to prevent deadlock. > > > In those cases, A cannot retake the mutex anyway. I.e., you just said > that you released the first mutex because you want to acquire a > different one. So those cases don't fit this example very well. >
Umm yes, then *after* aquiring the different one, A would like to retake the original mutex.
>> Another reason might be because we will be running for a very long >> time without requiring the lock. > > > And again in this case, A should not be immediately reacquiring the lock > if it doesn't actually need it. >
No, not immediately, I said "for a very long time". As in: A does not need the exclusion provided by the lock for a very long time so it drops it to avoid needless contention, then reaquires it when it finally does need the lock.
>> Or we might like to release it because >> we expect a higher priority process to take it. > > > And in this case, the expected behavior is the same as I've been pursuing. >
No, we're talking about what happens when A tries to aquire it again.
Just accept that my described scenario is legitimate then consider it in isolation rather than getting caught up in the superfluous details of how such a situation might come about.
-- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com
- 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/
| |