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: Realtime Programing on MacOSX

I agree with Scott, I recommend seting up a real time thread with then blocking it using nanosleep.

MacOSX's real-time scheduling is very, very good. But you should be aware of a few things. We implement 'real-time' by using a very high priority thread band. The real-time threads are even higher priority than the I/O threads. This can cause some problems especially if you do TOO MUCH at real time. Careful design is paramount.

The 20ms scheduling will be trivial so I shouldn't worry about that. The only thing that can hold of a real-time thread scheduling is another real time thread or blocking your thread in the kernel behind a funnel. The biggest users of real-time threads in our system is CoreAudio and its clients. Be warned there are Apps out there that can use > 75% of the available CPU at real-time priority, Garage Band & Logic spring to mind.

What sort of work are planning on doing at that high a priority?

Godfrey

On May 18, , at 18:44, Scott Lamb wrote:

On 18 May 2004, at 5:20 PM, RJ Auburn wrote:
I have a requirement that my thread wake up every 20ms no matter what. When I create timer using setitimer() it does indeed fire within about 1ms. The only problem is that I have with this model is that the signal gets dispatched to a random thread instead of my signal handling thread.

You want pthread_sigmask(); block SIGALRM in all threads but the one you want to receive it.

The other approach I looked into was to just call usleep() for the proper amount of time but the accuracy is very different. With that setup I get delays of several extra ms.

You might have better luck with nanosleep() than usleep().

Or maybe you could go directly to the Mach layer. If you peek at Libc/gen/nanosleep.c in Darwin CVS, you'll see that it's implemented with calls to clock_get_time() and clock_sleep_trap().

But my impression is that Mach is really not a real-time system, so I'm not sure how precise either way will be. A while ago, bbraun and landorf on #opendarwin were telling horror stories about signal latency. Maybe someone with first-hand knowledge will give more info.

Good luck.

Scott
_______________________________________________
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.
_______________________________________________
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: 
 >Realtime Programing on MacOSX (From: RJ Auburn <email@hidden>)
 >Re: Realtime Programing on MacOSX (From: Scott Lamb <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.