Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 Oct 2007 20:08:17 -0700
From:      Alfred Perlstein <alfred@freebsd.org>
To:        Kip Macy <kip.macy@gmail.com>
Cc:        Daniel Eischen <deischen@freebsd.org>, hackers@freebsd.org
Subject:   Re: Critical Sections for userland.
Message-ID:  <20071003030817.GP31826@elvis.mu.org>
In-Reply-To: <b1fa29170710022000h4e97fe71i39d340b3a0dc0936@mail.gmail.com>
References:  <20071003015231.GJ31826@elvis.mu.org> <Pine.GSO.4.64.0710022244250.626@sea.ntplx.net> <20071003025418.GN31826@elvis.mu.org> <b1fa29170710022000h4e97fe71i39d340b3a0dc0936@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
* Kip Macy <kip.macy@gmail.com> [071002 20:00] wrote:
> 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.

Yes there is...

The part that I ommitted detailed keeping a count of the number of
times this happens and if it exceeds a threshold then killing the
process.  Additionally, the kernel would write a byte into the user
shared area indicating, "please call me because you need to yield
after you're done with your critical section", if the kernel is not
listened to, then we beat the process with a rusty tire iron.

Sheesh, now can I get some help with this?

If I wanted this kind of treatment, I'd be asking on irc! :)

-- 
- Alfred Perlstein



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071003030817.GP31826>