On Thu, 4 Oct 2007, Alfred Perlstein wrote:
* Daniel Eischen <[EMAIL PROTECTED]> [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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
