Tim, thanks for that information. I had a look at the xnu source - you are right. The constraint won't prevent a real-time thread from starving non-realtime threads.
Julian On Tue, May 31, 2016 at 9:51 PM, Tim Hewett <[email protected]> wrote: > Julian, > > The constraints parameters were ignored in the kernel for many generations > of OS X in spite of the documentation defining their use. The real > documentation (the source code) said otherwise. > > I am not sure if they are still ignored, IIRC the kernel-side code is not > hard to find to check. > > Tim. > > > On 31 May 2016, at 20:00, [email protected] wrote: > > > Hi, > > > > I'm trying to create real-time threads via the > > THREAD_TIME_CONSTRAINT_POLICY. > > It works fine, an interrupt after each computation cycle can be seen > inside > > the profiler (Instruments / System Trace) but the constraint seems to be > > ignored. > > > > I would expect a penalty after the constraint time is over but the thread > > stays on the CPU starving other threads. > > > > That's the way I initialize the time constraint policy: > > > > thread_time_constraint_policy_data_t time_constraints; > > > > time_constraints.period = (int) NanosecondsToAbsolute (1000000); // 1 > > ms > > > > time_constraints.computation = (int) NanosecondsToAbsolute (250000); > // > > 0.25 ms > > > > time_constraints.constraint = (int) NanosecondsToAbsolute(500000); // > > 0.5 ms > > > > time_constraints.preemptible = 1; > > > > thread_policy_set(mach_thread_self (), THREAD_TIME_CONSTRAINT_POLICY, > > (thread_policy_t) &time_constraints, > THREAD_TIME_CONSTRAINT_POLICY_COUNT); > > > > Any ideas how to get the constraint working? > > > > Regards, > > Julian > >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
