Timer-queue timer callback proc and re-entrancy

Timer-queue timer callback proc and re-entrancy

Post by dan » Sat, 13 Mar 2010 04:29:36



What is the best practice to deal with re-entrancy issues in a callabck
function? As far as I understand, the callback function can be called by
different threads even if another callback is in progress. The only
exception seems to be a timer created with WT_EXECUTEINTIMERTHREAD flag. Am
I correct?

The on-line docs state that in case of WT_EXECUTEINTIMERTHREAD the timer
thread itself will invoke the callback but then the callback cannot perform
alertable wait because it is queued as APC (which might invoke another call
to the callback, I think).

Would it be OK for me to use a critical section to synchronize access to
resources with a timer interval set to ~16ms? What if the callback function
is called multiple times by the same thread in the pool? Is this possible?
I think that this is possible if the callback is queued as APC and the
currently executing callback waits in alertable state.

I'm looking for a reliable way to time Direct3D animations. timeSetEvent()
is no longer recommended so I'm trying to figure out how to use timer-queue
timers. I'm not sure if I can predict if a rendering code called from a
callback will perform alertable wait operation or not.

I'd appreciate any suggestions.

Thanks.
 
 
 

Timer-queue timer callback proc and re-entrancy

Post by m » Sat, 13 Mar 2010 09:17:45

IIRC the timer queue functions are closely related to, and built on top of,
the thread pool. If you have a UI thread, you can use WM_TIMER, or you can
use the thread pool (timer queue) and a sync object. The problem with the
latter is that several threads may wait to do a job that needn't be done at
all and all accesses will incur the cost of acquiring the sync object.