Critical Sections for userland.
alfred at freebsd.org
Tue Oct 2 20:22:43 PDT 2007
* Daniel Eischen <deischen at freebsd.org> [071002 20:16] wrote:
> On Tue, 2 Oct 2007, Alfred Perlstein wrote:
> >* Daniel Eischen <deischen at freebsd.org> [071002 20:02] wrote:
> >>On Tue, 2 Oct 2007, Alfred Perlstein 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:
> >>Well, yeah, but are you _really_ sure that you aren't just
> >>running something that should be real-time and have priority
> >>over other applications? SCHED_FIFO means you will run until
> >>you relinquish the CPU (you can only do this as root). If
> >>all your threads are well behaved, would this work? Have
> >>you tried it?
> >No, because it wouldn't work. How do we know when to let go
> >of the cpu? In my system, the kernel tells you without polling.
> You don't have to know when to "let go of the cpu" if your
> threads are well behaved (meaning they block on some event,
> or have periods when they wait). They will let go of the
> CPU normally. When they're busy, they will not be switched
> out (unless perhaps there is an interrupt thread that needs
> to run -- I'm not sure how real-time threads get scheduled
> against ithreads).
> If your threads are not well behaved (CPU hogs), then that
> isn't going to work because they'll probably bog down the
Yes, I know how threading works.
Unfortunately, your solution is not workable for us.
- Alfred Perlstein
More information about the freebsd-hackers