Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261428AbTETWxa (ORCPT ); Tue, 20 May 2003 18:53:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261414AbTETWxa (ORCPT ); Tue, 20 May 2003 18:53:30 -0400 Received: from mail.casabyte.com ([209.63.254.226]:56581 "EHLO mail.1casabyte.com") by vger.kernel.org with ESMTP id S261428AbTETWxO (ORCPT ); Tue, 20 May 2003 18:53:14 -0400 From: "Robert White" To: Cc: "Helge Hafting" , "Linux kernel" Subject: RE: recursive spinlocks. Shoot. Date: Tue, 20 May 2003 16:06:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1982 Lines: 52 -----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/