opensubscriber
   Find in this group all groups
 
Unknown more information…

c : coreaudio-api@lists.apple.com 5 January 2006 • 10:16PM -0500

Re: Correct API to implement a timer in a real-time thread
by Stéphane Letz

REPLY TO AUTHOR
 
REPLY TO GROUP





Le 5 janv. 06 à 13:54, philippe wicker a écrit :

>
> On Jan 5, 2006, at 12:25 PM, Stéphane Letz wrote:
>
>> Hi,
>>
>> We need to setup a 1 millisecond periodic timer used in a real-
>> time (time constraint) thread in a pure C console program. We  
>> first tried to use the carbon Timer manager  API (with NewTimerUPP  
>> and a timeManagerTask ...) but without being able to access the  
>> thread that call the timer task in order to setup its scheduling  
>> property to be  "time constraint".  We try also low-level function  
>> like mach_wait_until but had problems on Panther.
>>
>> What is the recommended way (API...) to implement a timer?
>
> Dunno if this is the recommended API but I would do it using the  
> POSIX API pthread_cond_timedwait (or alternatively  
> pthread_cond_timedwait_relative_np). Create your timer thread with  
> pthread_create, and call mach specific API to set the "time  
> constraint" scheduling policy. You could also use CoreAudio SDK  
> utilities CAPThread, CAMutex and CAGuard which are nice C++  
> encapsulations of POSIX thread, mutex and variable condition  
> concepts that allow you to do the same things in a simpler way.  
> "pthread_cond_timedwait" requires a mutex and a condvar. In your  
> case you'll use only the "time out" part of the API but you still  
> need to pass valid mutex and cond although the mutex will never be  
> signaled.  Just in case, be aware that  "pthread_cond_timedwait"  
> can spuriously return with a "no error (0)" status. To manage this  
> situation enclose the "pthread_cond_timedwait" call within a loop  
> such as:
>
> pthread_mutex_lock(mutex);
> int status;
> while (1) {
>   status  =  pthread_cond_timedwait(cond, mutex, absolute_time);
>   if (status  == EINVAL) break;  // ERROR: some invalid parameters
>   if (status  == ETIMEDOUT) break; // OK, the actual time-out
> }
> pthread_mutex_unlock(mutex);
> // Check the status and do the timer thread job
>
> It may not be necessary in your case to lock the mutex but I don't  
> know if the OS will correctly deal with that. It expects a locked  
> mutex at entry, unlocks it to put the caller thread to sleep and  
> relocks it when the thread has to wake up.
>
>>
>> Thanks
>>
>> Stephane Letz
>>

Hi Philippe,

Thanks for the info, actually I was wondering if a higher-level API  
was available because I would prefer not having to use function that  
"wait until a specified date". The thing is that when using this kind  
of functions, i have to deal with cases where an abnormal latency  
occur in the system, then the wait function returns too late, I have  
to compensate for that for the next interrupt and so on.

If I use a CoreAudio task as a way to schedule my 1 millisecond  
interrupt, the nice thing is that CoreAudio seems to automically  
ajust/compensate timing deviations. I can have a serie of call that  
on average is 1000us. I would like to have timer API that allows to  
setup the same thing.

Stephane

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list      (Coreaudio-api@list...)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/coreaudio-api/subscriber%40opensubscriber.com

This email sent to subscriber@open...

Bookmark with:

Delicious   Digg   reddit   Facebook   StumbleUpon

Related Messages

opensubscriber is not affiliated with the authors of this message nor responsible for its content.