Date: Tue, 2 Oct 2007 20:00:22 -0700 From: "Kip Macy" <kip.macy@gmail.com> To: "Alfred Perlstein" <alfred@freebsd.org> Cc: Daniel Eischen <deischen@freebsd.org>, hackers@freebsd.org Subject: Re: Critical Sections for userland. Message-ID: <b1fa29170710022000h4e97fe71i39d340b3a0dc0936@mail.gmail.com> In-Reply-To: <20071003025418.GN31826@elvis.mu.org> References: <20071003015231.GJ31826@elvis.mu.org> <Pine.GSO.4.64.0710022244250.626@sea.ntplx.net> <20071003025418.GN31826@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/2/07, Alfred Perlstein <alfred@freebsd.org> wrote: > * 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. :) I assume these processes are running as root? There is nothing to prevent the process from never dropping the lock. -Kip
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b1fa29170710022000h4e97fe71i39d340b3a0dc0936>