Attilio Rao wrote:
2007/10/3, Alfred Perlstein <[EMAIL PROTECTED]>:
* 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. :)
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
I suggest that we map a per-thread page into the address space
if it requests it. (and a per process page). The scheduler could look at
it for behavioural hints when it is present.
there are ways this could be done. it sort of dovetails into
work other people have been considering..
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
