Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S271162AbUJVA4J (ORCPT ); Thu, 21 Oct 2004 20:56:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S271146AbUJVAuS (ORCPT ); Thu, 21 Oct 2004 20:50:18 -0400 Received: from mail.timesys.com ([65.117.135.102]:35255 "EHLO exchange.timesys.com") by vger.kernel.org with ESMTP id S271052AbUJVAsC (ORCPT ); Thu, 21 Oct 2004 20:48:02 -0400 Message-ID: <41785879.1040805@timesys.com> Date: Thu, 21 Oct 2004 20:46:49 -0400 From: john cooper User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Esben Nielsen CC: Scott Wood , "Eugeny S. Mints" , Ingo Molnar , Thomas Gleixner , Jens Axboe , Rui Nuno Capela , LKML , Lee Revell , mark_h_johnson@raytheon.com, "K.R. Foley" , Bill Huey , Adam Heath , Florian Schmidt , Michal Schmidt , Fernando Pablo Lopez-Lezcano , john cooper Subject: Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8 References: In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2004 00:42:57.0968 (UTC) FILETIME=[1364F300:01C4B7D0] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1935 Lines: 45 Esben Nielsen wrote: >Anyway, I am not sure recursive acquisition is such a good idea: It will >make the mutex more expensive to use and promote sloppy coding where you >don't really know what mutexes are held right now. > In my experience I haven't quite found this to be the case. Rather allowing a lock/mutex/etc.. to be recursively acquired within a given path can greatly simplify APIs. Such as cases where a primitive acquires a lock internally which is also know by and suited to protect data in the caller's context. This avoids the "who has the lock?" information which must otherwise get stuffed into the API. Nested function calls simply observe correct lock usage at their respective levels and all unwinds correctly. The one notable place where this doesn't work is where locks must be conditionally acquired in an out-of-order sequence. However often these cases can be pushed out of the externally visible API. Another operational consideration is maintaining debug information in the lock. Keeping track of where each lock acquisition was made is at odds with a fixed sized lock data footprint. Still recursive acquisitions scale only with available stack space so a fair upper limit approximation is possible when running on fixed size stacks. Note I'm refering to single-owner spinlocks/mutexes here rather than reader/write locks. >I think it is better that the sloppy coder discoveres that he >deadlocks on himself before getting other sub-systems involved :-) > I agree. But I don't think the above precludes doing so. Detecting violations of unbalanced lock/unlock calls isn't really different than for non-recursive primitives. -john -- john.cooper@timesys.com - 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/