Re: Thread deadlock misery
- From: "Alexander Grigoriev" <alegr@xxxxxxxxxxxxx>
- Date: Tue, 13 Mar 2007 09:34:24 -0700
The real error is not in the GetTickCount() overflow. It's safe to calculate
elapsed time by subtracting it. It's NOT safe to just compare it.
The real error is that dwSleepTime is NEVER negative. If the execution is
behind, dwSleepTime is very big positive number, and the thread will sleep
pretty much forever.
"Ben Voigt" <rbv@xxxxxxxxxxxxx> wrote in message
news:O3SSkjYZHHA.3272@xxxxxxxxxxxxxxxxxxxxxxx
InterlockedIncrement( &pParent->m_nSentFrames );
DWORD dwSleepTime = ( 1000 / pATFP->TFP.FPS ) -
( GetTickCount() - dwStartTime );
if( dwSleepTime > 0 )
Sleep( dwSleepTime );
What happens when GetTickCount() overflows back to zero? Also, you're
accounting for the delay in your processing, but not the variation in
Sleep times, so your overall transmit rate is lower than you think. Use a
waitable timer instead.
.
- Follow-Ups:
- Re: Thread deadlock misery
- From: PaulH
- Re: Thread deadlock misery
- References:
- Thread deadlock misery
- From: PaulH
- Re: Thread deadlock misery
- From: Doug Harrison [MVP]
- Re: Thread deadlock misery
- From: PaulH
- Re: Thread deadlock misery
- From: Ben Voigt
- Thread deadlock misery
- Prev by Date: Re: ReadFille error caused by USB sniffer
- Next by Date: Re: Thread deadlock misery
- Previous by thread: Re: Thread deadlock misery
- Next by thread: Re: Thread deadlock misery
- Index(es):
Relevant Pages
|