Prev: Cheat anti-debuging application
Next: Same issue. Win2k3
From: dan on 11 Mar 2010 14:29

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.


From: m on 11 Mar 2010 19:17
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.

"dan" <dan(a)nospam.com> wrote in message
news:##i70EVwKHA.4552(a)TK2MSFTNGP04.phx.gbl...
>
> 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.
>
 | 
Pages: 1
Prev: Cheat anti-debuging application
Next: Same issue. Win2k3