From owner-freebsd-current Wed Jan 17 15:23:13 2001 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id ECA8937B400; Wed, 17 Jan 2001 15:22:52 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0HNMoQ05449; Wed, 17 Jan 2001 15:22:50 -0800 (PST) Date: Wed, 17 Jan 2001 15:22:50 -0800 From: Alfred Perlstein To: Bosko Milekic Cc: Randell Jesup , dillon@FreeBSD.ORG, Soren Schmidt , arch@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: HEADS-UP: await/asleep removal imminent Message-ID: <20010117152250.D7240@fw.wintelcom.net> References: <200101171138.MAA11834@freebsd.dk> <20010117092109.O7240@fw.wintelcom.net> <20010117100516.Q7240@fw.wintelcom.net> <012a01c080d5$fc532270$1f90c918@jehovah> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <012a01c080d5$fc532270$1f90c918@jehovah>; from bmilekic@technokratis.com on Wed, Jan 17, 2001 at 05:36:50PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Bosko Milekic [010117 14:35] wrote: > > Alfred Perlstein wrote: > > > Which means we don't have to drop the lock over the socket unless > > we'd block on allocation. > > No. You'd still have to drop it for now. Remember? (Last commit to > uipc_mbuf.c). You have to drop it because of the problem you may have if > Giant is gotten before your sockbuf/socket lock. In the allocation, you may > be acquiring Giant again. I don't know the exact semantics, but if you at > some point may grab the sockbuf/socket lock without already holding Giant and > call the allocation routine, you're opening the door for deadlock. The rest of the patches unwind giant on entry into the socket layer so grabbing Giant shouldn't be a problem. > > Matt, is this what you intended for it to do? So far I've only > > seen it used to avoid races, but not to optimize out mutex > > aquire/release. > > I've only seen it to be useful to avoid races. If you're holding a lock > and you need to sleep but if you drop the lock before you actually switch you > may get woken up and never find out, thus still going to sleep. With the > asleep you could hold the lock and place yourself on the sleep queue such > that when you drop the lock and call await, you'll find out if you've gotten > awoken (you'll be removed from the sleep queue). With the interlocking with > sched_lock now down in msleep(), this "feature" of asleep/await is useless. Read the rest of my posts, the ones not cc'd to everyone, just Matt and -arch. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message