>>From: Rik van Riel [mailto:riel@surriel.com]On Behalf Of Rik van Riel
>>
>
>>So call_EE_ messes with the data structure which call_ER_
>>has locked, unexpectedly because the recursive locking
>>doesn't show up as an error.
>>
>
>Yes and no. It all hinges on that nonsensical use of "unexpectedly".
>
>(I'll be using fully abstract examples from here on out to prevent the
>function call police from busting me again on a technicality... 8-)
>
Oh come on! Now I won't get into this argument, but you can't win
by saying "if this were implemented in such a way that recursive
locking is required, then recursive locking is required here"!!
Look: I could easily reimplement your snark so it doesn't have to call
the last "whangle" - now see how it can be done completely lockless
with a memory barrier between a and b?
Locking is an implementation issue, and as such I think you'll have
to come up with a real problem or some real code. You must have some
target problem in mind?
Best regards,
Nick
-
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/