From owner-freebsd-hackers  Thu Aug 17  9:17:24 2000
Delivered-To: freebsd-hackers@freebsd.org
Received: from viper.dmpriest.com (viper.dmpriest.com [195.188.177.3])
	by hub.freebsd.org (Postfix) with ESMTP id E93BB37B7C0
	for <hackers@freebsd.org>; Thu, 17 Aug 2000 09:17:14 -0700 (PDT)
Received: from tdx.co.uk (lorca.tdx.co.uk [195.188.177.195])
	by viper.dmpriest.com (8.9.3/8.9.3/Kp) with ESMTP id RAA01939;
	Thu, 17 Aug 2000 17:16:49 +0100 (BST)
Message-ID: <399C0FF1.2F97B106@tdx.co.uk>
Date: Thu, 17 Aug 2000 17:16:49 +0100
From: Karl Pielorz <kpielorz@tdx.co.uk>
Organization: The Digital eXchange
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Valentino Crimi <tcrimi+@andrew.cmu.edu>
Cc: hackers@freebsd.org
Subject: Re: Critical (or equivalent) section in Userland?
References: <399BA212.A84240AE@tdx.co.uk> <Utb0d7S00UwAMI3bU2@andrew.cmu.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Thomas Valentino Crimi wrote:

>   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).  I'm not sure if the same
> deadlock potential that exists with giving a process an idle priority
> exists due to locking in the kernel, although I see no mention of it in
> the man pages.  It's definitely something I'd be wary of, though.

Thanks, I'll look at that... Presumably, even though my process is making
syscalls, when they're completed - the scheduler _should_ look to run me
first, due to the very high priority?

If this doesn't work - I think I'm going to have to look to fixing the problem
(and removing the need to 'put the world on hold' while the program tinkers
with a few files)...

-Karl


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message