OS X timer resolution and rescheduling latency

I need to port an existing WIN32/Linux based application to OS X and would like to estimate if there are any potential roadblocks.

The application has "soft" real-time constraints.

Specifically, it has high-priority thread that needs to wake up at (possibly) high rate (down to 1 ms), do some checking, then most of the time yield almost immediately.

The purpose is beyond the scope of this message, but the design is not changeable (really not changeable), so please no comments about how it can be changed and whether it is valid or not (it is).

Logical structure of the thread is:

for (;;)

{

wait(event_object, timeout);

... do something ...

}

Thread needs to wake up when event_object is signaled or when timeout expires.

Timeout can vary depending on the situation, but can be down to 1 ms.

WIN32 version of the application uses timeBeginPeriod() to affect system scheduler and change scheduling quantum in situations that involve the thread.

Can you please advise whether this can be implemented under OS X as well, i.e. whether OS X is "truly preemtable".

This boils down to two issues:

1) If high-priority thread becomes computable (because event_object gets signalled or timeout expires), whether currently executing lower-priority thread will be preempted immediately or only at the next 100 Hz (kern.clockrate) clock tick.

2) What is the actual timer resolution of various OS X "wait" functions, for example pthread_cond_timedwait? Is it 1/100 (i.e. 10 ms) or 1 ms or below? Or does it depend on something and can be changed programmatically (like with timeBeginPeriod in Windows)?

To reiterate, the application is "soft" real time. It is ok if the thread does not get its way all the time (no aircraft is going to crash or patient die), but what is needed is that it usually gets scheduled as wanted, most of the time.

Thanks for your advise.