I've found it out for my program: I'm simply using
pthread_setschedparam() with SCHED_RR.
In fact it was my fault. In my former loop to acquire data I used:
FOREVER
{
gettimeofday(&tv, NULL);
if ( ((tv.tv_usec == 0 ) || ((tv.tv_usec >= HALF_SECONDS_IN_MICROSEC )
// Code acquire data
}
This will not work correctly, it will always miss some data.
But by using values for LOWER_TOLERANCE_MICROSEC of 100000
and UPPER_TOLERANCE_MICROSEC of 600000
it works perfectly....
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
