Re: Correct API to implement a timer in a real-time thread
Re: Correct API to implement a timer in a real-time thread
- Subject: Re: Correct API to implement a timer in a real-time thread
- From: philippe wicker <email@hidden>
- Date: Thu, 5 Jan 2006 13:54:49 +0100
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden