opensubscriber
   Find in this group all groups
 
Unknown more information…

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

Re: Correct API to implement a timer in a real-time thread
by philippe wicker

REPLY TO AUTHOR
 
REPLY TO GROUP





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
>
>
> _______________________________________________
> 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/pwicker%40mac.com
>
> This email sent to pwicker@mac....
>

_______________________________________________
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.