From owner-freebsd-hackers@FreeBSD.ORG  Wed Oct  3 02:54:19 2007
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
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 22E1016A418;
	Wed,  3 Oct 2007 02:54:19 +0000 (UTC)
	(envelope-from bright@elvis.mu.org)
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
	by mx1.freebsd.org (Postfix) with ESMTP id 1C17713C458;
	Wed,  3 Oct 2007 02:54:19 +0000 (UTC)
	(envelope-from bright@elvis.mu.org)
Received: by elvis.mu.org (Postfix, from userid 1192)
	id E921D1A4D7E; Tue,  2 Oct 2007 19:54:18 -0700 (PDT)
Date: Tue, 2 Oct 2007 19:54:18 -0700
From: Alfred Perlstein <alfred@freebsd.org>
To: Daniel Eischen <deischen@freebsd.org>
Message-ID: <20071003025418.GN31826@elvis.mu.org>
References: <20071003015231.GJ31826@elvis.mu.org>
	<Pine.GSO.4.64.0710022244250.626@sea.ntplx.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.64.0710022244250.626@sea.ntplx.net>
User-Agent: Mutt/1.4.2.3i
Cc: hackers@freebsd.org
Subject: Re: Critical Sections for userland.
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Oct 2007 02:54:19 -0000

* Daniel Eischen <deischen@freebsd.org> [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:

/* assume single threaded process for now */
static int is_critical;



atomic_mutex_lock();  /* implies ++is_critical */
 ...do stuff...
atomic_mutex_unlock(); /* implies --is_critical */

We don't want two or more syscalls per lock operation. :)

-- 
- Alfred Perlstein