Re: Critical Sections for userland.

["Attilio Rao" <attilio_(_at_)_freebsd_(_dot_)_org>]

2007/10/3, Alfred Perlstein <alfred_(_at_)_freebsd_(_dot_)_org>:
> * Daniel Eischen <deischen_(_at_)_freebsd_(_dot_)_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. :)

Basically, preemption in kernelspace is handled by using the
td_critnest counter which should work in this way:
- critical_enter() bumps td_critnest
- if preemption is required or an ipi arrives and the operation is
signalled with the td_owepreempt flag and will be deferred.
- once critical_exit() is called the counter is decreased. If
necessary (checking for td_critnest and td_owepreempt) the preemptive
operation happens instantanely.

It is all very fast and highly scalable as scope of operation is
entirely per-thread so it doesn't require any lock. I think maybe you
should use a very similar scheme to this.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
_______________________________________________
freebsd-hackers_(_at_)_freebsd_(_dot_)_org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe_(_at_)_freebsd_(_dot_)_org"