Critical Sections for userland.

[Daniel Eischen]

On Thu, 4 Oct 2007, Alfred Perlstein wrote:

> * Daniel Eischen <deischen at freebsd.org> [071004 06:05] wrote:
>>
>> His point about telling us what you're really doing, so we might
>> off other ways to do it is valid.
>>
>> We don't know why you are using homegrown user-level spinlocks
>> instead of pthread mutexes.  Priority ceiling mutexes and running
>> in SCHED_RR or SCHED_FIFO is really what tries to address this
>> problem, at least from the vague desciption you give.  If you
>> have tried this and they don't work correctly, then one solution
>> is to fix them ;-)
>
> First of all we're stuck on 6.x, how is threads on this platform?

I don't _think_ there is anything prohibitive of MFC'ing
any libthr bug fixes into 6.x.  I would have thought that
you would have tried libthr on 6.x and possibly offered up
"libthr performance sucks for me, and here's why" :-)

You should probably ask David Xu about priority ceiling
mutexes work on 6.x.

> Second off we are contending against other devices in the system
> that do not run FreeBSD, How do we address that?

If you're running in real-time, then you are suppose to have
priority over anything else except for ithreads.  How much
interrupt load is on your system and is ithread processing
really going to impact you?  If everything is working correctly
and your thread that holds a priority ceiling mutex gets
swapped out for an ithread, that thread should run again
after the ithread.  It shouldn't get swapped out for a
different thread that doesn't also have its priority
elevated (due to holding a similar mutex).

I don't know if anyone other than possibly David Xu have
tested SCHED_RR or SCHED_FIFO and priority ceiling mutexes,
so they may not work as they're suppose to.

-- 
DE