Pardon ? I can't believe I'm hearing this. You simply can't do what
you want to do, and not expect potential deadlocks. There's tons of
papers on this from CS theory folk, and you just can't get away with
it. Sorry.
What you want is:
lock(some_lock);
CRITICAL_SECTION:
.
.
.
condition_wait (some_condition, some_lock);
END_CRITICAL_SECTION:
unlock (some_lock);
where condition_wait releases the lock, and calls schedule. When it
returns (because someone did condition_signal (some_condition)), you
hold the lock again.
Of course, this means you can't write the code for CRITICAL_SECTION as
if you held the lock the whole time. But if the kernel or you calls
schedule() while you hold the lock, then you *inevitably* have a
potential deadlock situation and there is no way around it.
It may be that the deadlock in question will never arise for other
reasons, or that when it does, you don't care. But you *CANNOT* do
what you show above and not have a potential deadlock.
--p
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/