On Thu, 4 Oct 2007, Alfred Perlstein wrote:
* Dag-Erling Sm??rgrav <[EMAIL PROTECTED]> [071004 03:01] wrote:
Alfred Perlstein <[EMAIL PROTECTED]> writes:
Do you have:
a) Evidence or a paper to prove that this is a bad idea?
I need evidence or a paper to prove that it is a bad idea to allow a
userland process to hold the CPU indefinitely?
b) A helpful suggestion?
Why don't you tell us what you're actually trying to do, so we can tell
you how to do it.
c) An obvious understanding of the problem?
I'll show you mine if you show me yours.
It's not worth my time to engage someone with your mind set, you
posses neither the technical nor interpersonal skill to be useful
to me.
For context see my replies in this thread to Kip Macy which explains
how one deals with the false-problems you mention.
For evidence of existing, however suboptimal, run-to-completion
systems see the RTPRIO scheduling knobs.
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 ;-)
--
DE
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
