Re: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow)
From: Nick Piggin
Date: Thu Jan 26 2006 - 17:23:17 EST
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/