-----Original Message-----
From: Richard B. Johnson [mailto:root@chaos.analogic.com]
> The lock must guarantee that recursion is not allowed. Or to put
> it more bluntly, the lock must result in a single thread of execution
> through the locked object.
Where the HECK do you get that load of bull? The one requirement of a
MUTUAL EXCLUSION PRIMITIVE (a.k.a. mutex, a.k.a. lock) is *MUTUAL*
EXCLUSIVITY.
Nothing else. Lets look at the words:
Mutual - "directed by *each* toward the *other* or *others*" (e.g. not self,
duh) {all other definitions talk about group insurance, which applies too
8-)
Exclusion -> exclude -> "To prevent or restrict entrance" (etc.) "to bar
from participation"
So, a mutex erects a "bar to/from participation" "directed by each (holder)
to other (would be holder(s))".
There is no concept of "Self Exclusion" in a lock (mutex et. al.) so
recursion, by definition, is (or should be) permitted.
All else is unfounded blither.
The fact is, that it is easier to write locks that will self dead-lock and
lazy people, acting in the name of expediency, decided that somehow, such
locks were "better" because they didn't want to expend the effort to make
them correct. Still others then try to stand on lazy precedent as if it is
somehow cannon.
The only place/way you can argue this is if the constituent operations "X"
within a larger body of code Alpha are not considered part of Alpha (re, the
previous Alpha is composed of X and others example). But that is like
yelling "I locked it, so my arm, which is not all of me, should not be
allowed to use it because my arm is not me..."
>From the standpoint of purely logical analysis, this is a little esoteric...
and obviously specious tripe.
Rob.
-
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/
This archive was generated by hypermail 2b29 : Fri May 23 2003 - 22:00:42 EST