Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753911AbXFXQp5 (ORCPT ); Sun, 24 Jun 2007 12:45:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751282AbXFXQpu (ORCPT ); Sun, 24 Jun 2007 12:45:50 -0400 Received: from nz-out-0506.google.com ([64.233.162.235]:49781 "EHLO nz-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750927AbXFXQpt (ORCPT ); Sun, 24 Jun 2007 12:45:49 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PUtd38K1QihrD34QFgR+kWjshIBOUZY5xqYl1QQrRu/SK9pUkZQlVLTzr33cLy/UjL9JpXgw7rB54U3g5uyr6cBFVxkG+F7oO5JR4LgGZn9t5M0OcRV4o7/lkQbEtOM2mG0eYOSU3kdXbxAM0QJJ7OPbGtGEk8/jEiF+9CiQMv4= Message-ID: Date: Sun, 24 Jun 2007 22:15:48 +0530 From: "Satyam Sharma" To: "Robert P. J. Day" Subject: Re: "upping" a semaphore from interrupt context? Cc: "Arnd Bergmann" , "Florin Iucha" , "Linux Kernel Mailing List" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070622173839.GB8398@iucha.net> <200706221934.18436.arnd@arndb.de> <200706231402.03617.arnd@arndb.de> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2135 Lines: 47 Hi Robert, On 6/24/07, Robert P. J. Day wrote: > On Sat, 23 Jun 2007, Satyam Sharma wrote: > > > On 6/23/07, Robert P. J. Day wrote: > > > > hang on, how is that true? as i read it, mutexes are more than > > > just binary semaphores -- they have additional restrictions that > > > regular semaphores don't. > > > > Yes, they do have additional restrictions (mutex_trylock() illegal > > from contexts that cannot sleep, mutexes may only be unlocked by > > tasks that took them in the first place). But note that these are > > _implementation_ sanity checks that were introduced to catch > > nonsensical usage, which was possible (and not explicitly being > > guarded against, because of the generic-ness that was needed to be > > maintained for the counted case too) with the "semaphore"s. > > > > > so i'm not convinced that binary semaphores can simply be replaced > > > by mutexes, unless that's not what you meant here. > > > > I do mean precisely that. I really cannot think of any sensible / > > normal usage case of binary semaphores that cannot be replaced with > > either mutexes (if that's the kind of locking you actually want) or > > completion handlers (if that's the kind of synchronization you > > actually want). > > ok, i can see what you're getting at now. i'm just going to have to > convince myself that, once you have mutexes and completions, you have > no further need for even general counting semaphores. Whoa, hold on. But I've been explicitly mentioning *binary* semaphores all along! Of course users who want / allow multiple tasks (but only upto a specific maximum number, which is what counted semaphores are all about) to be present in a given critical section simultaneously would still want to use the _counted_ semaphores, which is why you won't see the old "struct semaphores" dying anytime soon. Satyam - 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/