Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 8 Feb 2002 03:21:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 8 Feb 2002 03:21:06 -0500 Received: from nrg.org ([216.101.165.106]:33594 "EHLO nrg.org") by vger.kernel.org with ESMTP id ; Fri, 8 Feb 2002 03:20:54 -0500 Date: Fri, 8 Feb 2002 00:20:37 -0800 (PST) From: Nigel Gamble Reply-To: nigel@nrg.org To: Andrew Morton cc: Robert Love , Martin Wirth , , Subject: Re: [RFC] New locking primitive for 2.5 In-Reply-To: <3C62D49A.4CBB6295@zip.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 7 Feb 2002, Andrew Morton wrote: > I dunno. The spin-a-bit-then-sleep lock has always struck me as > i_dont_know_what_the_fuck_im_doing_lock(). Martin's approach puts > the decision in the hands of the programmer, rather than saying > "Oh gee I goofed" at runtime. I completely agree, and I couldn't have put it better! Kernel programmers really should know exactly why, what, where and for how long they are holding a lock. This is why, incidently, I don't like any of the so-called lockless schemes, including the original unix kernel monitor lock (i.e. only one kernel thread active at a time), because they encourage unmaintainable code where the critical sections are invisible to everyone and are easily broken when someone accidently inserts a blocking function into one of the invisible critical sections. Nigel Gamble nigel@nrg.org Mountain View, CA, USA. http://www.nrg.org/ - 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/