MacOS and OS X are entirely different operating systems. MacOS used cooperative multi-tasking and its thread behaviour is/was totally unrelated to what happens in OS X, which uses preemptive multi-tasking. The kernel of OS X bears essentially zero relationship to MacOS.
On Wed, Jun 1, 2016 at 12:12 PM, Tim Hewett <[email protected]> wrote: > Julian, > > There used to be a (IIRC) 5 second time limit for stuck / runaway real > time threads where it would be terminated by the OS to save the rest of the > system - in the old days of single core Macs they were capable of hanging > the whole computer including the mouse pointer, so the OS put a limit on > them otherwise it wasn’t possible to get control back. This limit could be > changed using an NVRAM parameter if needed. > > This implicitly conveys a point which is that it would be impossible for a > single real time thread to freeze a multi core Mac, perhaps this is of help? > > Tim. > > > On 1 Jun 2016, at 10:00, Julian Dessecker <[email protected]> wrote: > > > 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/paul%40linuxaudiosystems.com > > This email sent to [email protected] >
_______________________________________________ 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]
