Critical Sections for userland.

[Julian Elischer]

Attilio Rao wrote:
> 2007/10/3, Alfred Perlstein <alfred at freebsd.org>:
>> * 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. :)
> 
> 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..