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

G'day RJ,

I'm not sure what the user land APIs are to set a thread to real-time (I have never had to do it, we tend to use kernel_thread priority in the kernel and I can sometimes parasite off a user's realtime thread), I'm sure somebody on the list can better answer that question.

So would it be correct that your real-time thread is going to be something like (Pseudo code)

thread_main(int so)
{
thread(realtime);

nexttime = now();

for (;;) {
int size, delay;
char *block = get_next_block(&size);

nextime += HEARTBEAT_INTERVAL;

write(so, block, size);
delay = nexttime - now();
nonosleep(delay);
}
}

This thread can have a number of problems.

1> get_next_block is presumably synchronising with something, so you can stall in the lock there, bit opportunity for a priority inversion if you aren't careful (beware spin locks)
2> write(so...), this is going to be the nastiest problem. Your nice real time thread is going to try to take the network funnel. We only have ONE network funnel in the system and that is going to cause you problems I suspect.
3> Your thread is competing with other realtime threads operating in the system.

Diagnosis :-
1> Instrument your thread with clock_get_uptime sprinkled all the way through it. Where you are blocking is important. If you are having problems with your synchronisers try using a single producer/single consumer queue which doesn't usually require a lock (needs to be written very carefully though)

2> Check out fs_usage. It may help you track down who is doing what on the system.

3> sudo latency -rt -st 20000 -l /tmp/lat.log. See latency(1)

Hope this helps

Godfrey

On May 19, , at 10:41, RJ Auburn wrote:

*This message was transferred with a trial version of CommuniGate(tm) Pro*
On May 19, 2004, at 10:13, Godfrey van der Linden wrote:
I agree with Scott, I recommend seting up a real time thread with then blocking it using nanosleep.

From reading the usleep source it looks like I should be able to use it also as it just calls nanosleep() under the covers.

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.

I my case it will be sending RTP data over the network. I should be able to limit the amount of time needed.

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.

This will be a server based app so I should be ok as there will not be any other CoreAudio type apps running with me.

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

Voice over IP systems. I need to be able to pump audio around over the network using RTP and VoIP gets very picky if it does not get sent on time.


As an FYI this approach (usleep + realtime thread) is seeming to be working for the most part currently. There still are some weird delays (30-200ms) at times but I need to do some digging to make sure that something inside my code and network libs is not blocking and causing the problems.

I am currently using the thread_policy_set() call to set my self as real time priority. Is there any other functions you recommend calling to let the system know that it is a critcal thread?

Thanks for the help.

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