* Kip Macy <[EMAIL PROTECTED]> [071002 20:00] wrote: > On 10/2/07, Alfred Perlstein <[EMAIL PROTECTED]> wrote: > > * Daniel Eischen <[EMAIL PROTECTED]> [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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"