Re: Thread Pre-Emption Question . . .

Rob,

As indicated by another poster, WIN32 isn't a RTOS (RealTime OS) so might be blewing against the wind here to get some kind of perfection.

Also, you have the QUANTUM, in the RTOS world, one might view that as the "residence time". In Windows, the quantum is around ~10 to ~15ms. I say, with todays CPU/NT based machines, its closer to ~15ms. Use the api GetSystemTimeAdjusment() to get the clock interval for the machine.


So in *Theory*, your thread has maximum of two to three quantums (40/~15) if its not itself pre-empting itself or has any kernel object waits. That means if your code is not doing anything kernel objects that will change the scheduler, then the OP CODES add up to the quantum and that will define when the code will be pre-empted.

You can play with the process class and thread priorities which will alter the windows thread scheduler logic to run your thread before others given it more "residence time." Otherwise, it tries to emulate a round-robin concept for equal priority threads.

You might also play around with multi-media timers (mmsystem.h), timeBeginPeriod(resolution), timeBeginEnd(resolution). This might help your application, depending on what you are doing.

--
HLS


Rob wrote:
Hi,

I'm developing a real-time application in C++ & MFC/Win32. I have a worker thread that sits in a loop doing a lot of processing, it looks a little like this,

UINT WorkerThread(LPVOID pParam)
{

while(1)
{
// Wait for event to be singled (happens precisely every 40ms)
If (waitForEvent() == ABORT)
break;

/*
Lots of processing here (its crucial it doesn’t take more than 40ms)
The time taken to process this block is measured using the PC’s Performance timer and an error generated if it’s taken too long
*/
}

return 0;
}

In the extreme cases when the processing takes longer than 40ms I'd like to know if it was caused by me trying to do too much processing or by another thread or process pre-empting this thread. Does anyone know of a reliable way I could work this out?

Cheers
Rob.


.