Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: THREAD_TIME_CONSTRAINT_POLICY

On Feb 18, 2004, at 10:55 PM, Peter April wrote:
> I'm calling thread_policy_set() with THREAD_TIME_CONSTRAINT_POLICY to
> improve the performance of a real-time thread. I notice that under OS
> X 10.2.8 for 1.8GHz G5, thread_policy_set returns a PARAM_ERROR (4) if
> I pass it tcPolicy.computation greater than about 1600000,
> corresponding to about 1.8 milliseconds. This limitation is
> independant of the value I pass in tcPolicy.period and
> tcPolicy.preemptible. I can't figure out why the scheduler would
> choke on my request for a larger chunk of CPU time. What's really odd
> is that thread_policy_set() returns KERN_SUCCESS even if I request
> tcPolicy.period/computation/constraint all set to 1600000, presumably
> smiling upon my request for 100% of the CPU time!

Please file a bug report for these kinds of issues. That way somebody
will at least constantly be reminded to look into the issue you report.
Sending a code snippet that compiles and reproduces the problem will
almost always result in a quicker response. Given that we don't
currently use those parameters in the priority calculation for
time-constraint threads,

> Of course, the irritating part of all this is that no matter what I
> pass, my thread still gets thrown out for up to 10ms at a time, even
> if I'm the only app running, trueblue is shutdown, and the update task
> has been killed :(
> Any pointers on improving real-time performance would be greatly
> appreciated.

First the obligatory statement: "This is not a public API, and the
behavior of thread_policy_set() may change from release to release."
In particular, we expect it to be set by using other frameworks (like
CoreAudio) that carefully control the other APIs that are called while
declared a time-critical thread. That's because not all system APIs
have bounded priority inversions - they may allow lower priority
threads to lock out time-constraint threads for periods of time that
exceed expected latencies. So, we need to know what APIs you are
calling as a time-constraint thread to determine if that 10ms "throw
out" is expected or not.

The other issue is that becoming a time-constraint thread is not a
privileged operation. Therefore, to assure you don't launch an
accidental denial-of-service attack on the system, we regulate the CPU
usage of such threads. If they run too long without blocking, we
remove their time-constraint behavior and revert them to a regularly
scheduled thread. That CPU-hog time limit is on the order of seconds.
Certainly long enough for reasonable threads to get their work done and
volunteer to block. Therefore, if you are not blocking, you may not
actually be running as a time-constraint thread anymore.

Either way, more information is needed before much more help could be
provided.
--Jim

[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
darwin-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development
Do not post admin requests to the list. They will be ignored.
References: 
 >THREAD_TIME_CONSTRAINT_POLICY (From: Peter April <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.