Jim, Thank you very much for the thorough response. Admittedly I was surprised to learn that the thread_time_constraint_policy settings aren't really implemented; it explains why changing the values didn't alter the behavior. As a first cut, I think I will experiment with using the THREAD_EXTENDED_POLICY and setting info->timeshare FALSE. I haven't been able to locate any reference in the API docs to THREAD_EXTENDED_POLICY. Is this documented somewhere? -Michelle -----Original Message----- From: darwin-kernel-admin@lists.apple.com [mailto:darwin-kernel-admin@lists.apple.com]On Behalf Of Jim Magee Sent: Thursday, July 22, 2004 4:18 PM To: Michelle Munson Cc: darwin-kernel@lists.apple.com Subject: Re: problem with real-time scheduling On Jul 22, 2004, at 5:01 PM, Michelle Munson wrote:

Using the real-time API for the Mach kernel

(set_thread_priority(...)), we

are able to guarantee our application thread enough of the CPU to run

fairly

smoothly even when another process is competing. However, now the

behavior

we observe is that when our process has run smoothly for a while at

high CPU

usage (approx 70-80% for example), it will be suddenly "demoted" by the

scheduler to a very low CPU%. Piecing together background from the

kernel

programming documentation on Apple's developer site, I believe that

this

"demotion" effect happens because the scheduler automatically demotes

processes deemed to be taking too much of the CPU.

What's surprising is that we are using "reasonable"

thread_time_constraint_policy settings. We have experimented with a

range of

values based on examples from Apple and other "real-time" applications

such

as audio and video players. We are taking a high but still reasonable

percentage of the CPU.

It doesn't matter what you set for the scheduler settings. Unless you explicitly block or yield the CPU, the scheduler doesn't know that you haven't just overrun your defined computation and need more time to complete. So, it gives it to you (in fact, besides some sanity checks, those values are ignored in the current implementation of the scheduler - but will be used at some future date). It is your application/thread's behavior, and not its "supposed to work this way" scheduler definition - that determines whether it is hogging the CPU (today, that's defined as running for 8 seconds in realtime mode without ever once yielding the CPU away or blocking).

So the basic question is, is there a way that we can guarantee that our

process will not be completely stopped when competing processes launch

other

than using the real-time API? And if we need to use the real-time API,

is

there a way we can avoid the demotion effect, for example, yield to

other

processes when necessary?

Because your thread is consuming tons of CPU time - and is running under a timeshare (priority adjusting) policy - it probably is degrading to just above an idle thread by the time the other process launches. It's no wonder it is then taking a big chunk of the CPU away from you - before the scheduler finally adjusts you back up to where you can fairly compete for the CPU. The method used to yield the CPU from time to time (and avoid losing your time-constraint policy setting) depends upon the programming mode of the application. If it is Carbon, WaitNextEvent(), or better yet, going back to the runloop does the trick (the latter works for Cocoa too). Using usleep() or select() from a Unix application will also do it. If you can't yield any time explicitly (or go back to the runloop), you can take the timeshare (adjusting priority) nature of your process away without boosting it into higher priorities of time-constrained threads. The typical solution is to use thread_policy_set(THREAD_EXTENDED_POLICY) setting the info->timeshare to FALSE. In addition, we have found the setting your priority lower by just a few notches helps when doing this. It allows a timeslice or two for other processes before they degrade below your priority - giving reasonable response time for them and relatively low latency for you (since you will always be near the top of the priority scale for "normal threads - and they don't stay at the top for very long if they are timeshare). --Jim [demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored. _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.