Critical Sections for userland.

[Alfred Perlstein]

* Kip Macy <kip.macy at gmail.com> [071002 20:00] wrote:
> On 10/2/07, Alfred Perlstein <alfred at freebsd.org> wrote:
> > * Daniel Eischen <deischen at 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