From owner-freebsd-hackers Thu Aug 17 10: 7:40 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id B62DF37BA3B for ; Thu, 17 Aug 2000 10:05:29 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id KAA27151; Thu, 17 Aug 2000 10:05:19 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id KAA08322; Thu, 17 Aug 2000 10:05:18 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Thu, 17 Aug 2000 10:05:18 -0700 (PDT) Message-Id: <200008171705.KAA08322@vashon.polstra.com> To: hackers@freebsd.org Reply-To: hackers@freebsd.org Cc: tcrimi+@andrew.cmu.edu Subject: Re: Critical (or equivalent) section in Userland? In-Reply-To: References: <399BA212.A84240AE@tdx.co.uk> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article , Thomas Valentino Crimi wrote: > > going to be around 6 or 7 calls to rename() but I must ensure they _all_ > > happen before any other process is allowed to run again... > > Take a look at rtprio(2), giving yourself a realtime priority will > guarantee you the CPU until you explicitly release it (or another higher > priority realtime process comes along). It's generally a bad idea to use priorities to try to guarantee exclusive access. Think SMP. If there are enough CPUs in the system, all runnable processes will be running no matter what their priorities are. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message