From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 4 13:05:27 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E44E816A420; Thu, 4 Oct 2007 13:05:27 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id A4F4B13C494; Thu, 4 Oct 2007 13:05:27 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.1/8.14.1/NETPLEX) with ESMTP id l94D5Ojt004561; Thu, 4 Oct 2007 09:05:24 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.netplex.net [204.213.176.10]); Thu, 04 Oct 2007 09:05:24 -0400 (EDT) Date: Thu, 4 Oct 2007 09:05:24 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Alfred Perlstein In-Reply-To: <20071004101902.GN31826@elvis.mu.org> Message-ID: References: <20071003015231.GJ31826@elvis.mu.org> <86zlyzqmgo.fsf@ds4.des.no> <20071004094821.GM31826@elvis.mu.org> <86ejgbqjvr.fsf@ds4.des.no> <20071004101902.GN31826@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Dag-Erling Sm??rgrav , hackers@freebsd.org Subject: Re: Critical Sections for userland. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2007 13:05:28 -0000 On Thu, 4 Oct 2007, Alfred Perlstein wrote: > * Dag-Erling Sm??rgrav [071004 03:01] wrote: >> Alfred Perlstein writes: >>> Do you have: >>> >>> a) Evidence or a paper to prove that this is a bad idea? >> >> I need evidence or a paper to prove that it is a bad idea to allow a >> userland process to hold the CPU indefinitely? >> >>> b) A helpful suggestion? >> >> Why don't you tell us what you're actually trying to do, so we can tell >> you how to do it. >> >>> c) An obvious understanding of the problem? >> >> I'll show you mine if you show me yours. > > It's not worth my time to engage someone with your mind set, you > posses neither the technical nor interpersonal skill to be useful > to me. > > For context see my replies in this thread to Kip Macy which explains > how one deals with the false-problems you mention. > > For evidence of existing, however suboptimal, run-to-completion > systems see the RTPRIO scheduling knobs. His point about telling us what you're really doing, so we might off other ways to do it is valid. We don't know why you are using homegrown user-level spinlocks instead of pthread mutexes. Priority ceiling mutexes and running in SCHED_RR or SCHED_FIFO is really what tries to address this problem, at least from the vague desciption you give. If you have tried this and they don't work correctly, then one solution is to fix them ;-) -- DE