From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 3 03:02:09 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 8500B16A41B; Wed, 3 Oct 2007 03:02:09 +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 2D0AD13C480; Wed, 3 Oct 2007 03:02:09 +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 l93327hb017389; Tue, 2 Oct 2007 23:02:07 -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]); Tue, 02 Oct 2007 23:02:08 -0400 (EDT) Date: Tue, 2 Oct 2007 23:02:07 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Alfred Perlstein In-Reply-To: <20071003025418.GN31826@elvis.mu.org> Message-ID: References: <20071003015231.GJ31826@elvis.mu.org> <20071003025418.GN31826@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 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: Wed, 03 Oct 2007 03:02:09 -0000 On Tue, 2 Oct 2007, Alfred Perlstein wrote: > * Daniel Eischen [071002 19:46] wrote: >> On Tue, 2 Oct 2007, Alfred Perlstein wrote: >> >>> Hi guys, we need critical sections for userland here. >>> >>> This is basically to avoid a process being switched out while holding >>> a user level spinlock. >> >> Setting the scheduling class to real-time and using SCHED_FIFO >> and adjusting the thread priority around the lock doesn't work? > > Too heavy weight, we want to basically have this sort of code > in userland: Well, yeah, but are you _really_ sure that you aren't just running something that should be real-time and have priority over other applications? SCHED_FIFO means you will run until you relinquish the CPU (you can only do this as root). If all your threads are well behaved, would this work? Have you tried it? Are you trying to prevent switching out of the thread amongst other threads of the same application, or all threads in the system? -- DE