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: kern/clock.h error on MacOSX 10.4.3 & Xcode 2.2




On Nov 23, 2005, at 11:38 AM, Gilles Celli wrote:
This maybe off topic but I just want to simply acquire data from a multimeter every 0.5seconds, this seems to work quite good without realtime priority,
however sometimes it misses some values at a given time...so I thought to turn realtime on:


So what I need is AbsoluteTime to set realtime priority, but the result of mach_absolute_time() from the above document
is different from the one which should be used in chapter "Using the Mach Thread API to Influence Scheduling"
http://developer.apple.com/documentation/Darwin/Conceptual/ KernelProgramming/scheduler/chapter_8_section_4.html


I'm developing on a "mac Mini" with a bus speed of 133MHz I used the values of "period, computation and constraint"
as described in the document:
It seems to block the Mac for 8s seconds... before continuing...


So maybe these values are incorrect or can someone explain this lock ?

On single CPU systems, a runaway realtime thread will appear to freeze the system. There is a monitor build into the scheduler. If a realtime thread goes compute bound for 8 seconds, it will be returned to normal application thread scheduling to "unfreeze" the system. So, it sounds like your thread is a runaway.


An important note, those scheduling parameters for time constraint threads just give the scheduler some values to work with in computing scheduling behavior. They do not force injection of blocking points. Your thread still has to block itself waiting for whatever event triggers its next iteration. In your case, most likely a timer. This block will keep your application from being considered a runaway, and you should be fine.

But, more importantly, one has to ask why you needed realtime behavior for a 0.5 second loop. That should be handled fine via normal scheduling - again unless you let your application is a runaway "polling" (and thus getting its priority reduced down towards idle/background activity threads).

It sounds like you could just get rid of the polling and remove the need for realtime altogether.

--Jim

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Unix-porting mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/unix-porting/email@hidden

This email sent to 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.