Threads and system clock

I hope it will help:
http://www.cryer.co.uk/brian/delphi/howto_time_code.htm
http://delphi-snippets.blogspot.com/
The main idea is to use QueryPerformanceCounter:
http://www.festra.com/wwwboard/messages/13154.html 
http://delphiforfun.org/Programs/Delphi_Techniques/timing.htm
 

Dear Pavel,

Thanks for your quick reply and the useful links.

I am afraid that I was not clear enough. I need to use the timer for an action that needs to take place 100-250 times a second.

My problem is that when my program is hard at work, I stop getting timer ticks for more than 2 seconds, which is very bad for me.

Thanks,
Asaf

I answered - I think you need to use QueryPerformanceCounter. Please read my previous comment. Two last links contain a Delphi code and an explanation.
 
 

Dear Pavel,

Thanks again for your reply. If I read correctly, the links you had sent are about timing Delphi code, i.e. measuring the time it takes to execute a block of code. Am I right?

What I am after is a solution that would allow me get timer ticks as an event. My code needs to execute an action 100-250 times a second. It currently depends on inter's solution and stops working for almost 3 seconds when the program is busy.

I am after a robust way of getting my tick events every 4 ms, allowing temporarily faults of up to 50ms, but no longer.

Thanks,
Asaf

The issue is probably that when your app is busy it isn't able to handle handle timer messages. When this occurs Windows will stop sending them until the backlog is cleared. You may have to rework your code. I don't think that receiving a timer message every 4ms is realistic.

Yes, you understand correctly.

I hope I understand. The code you are using right now is the Windows timer set for 4 msec.
I'd say this is already a mistake. Firstly, because you cannot expect such quality from the windows timer. Secondly, if the operation you perform on the timer event takes longer than 4 msec (for example, you redraw the window)... you are in a logical problem. One more point, the timer message has almost the lowest priority.

In such case, I'd say, you need to use the idle time of the window message loop (if you know how to get there with Delphi). If it is about graphics - you need to use the double buffering. Many OpenGL applications uses this way. I think, this the right way that every one here will recommend.

You may create a thread with WaitForMultipleObjects inside that will post a message to your window (or call invalidate) - it's, actually, the same as you use now, but, I trust more to WaitForMultipleObjects. You understand that WaitMultipleObjects in this case is just Sleep(4).

I'd like to thank you, again, for having replied, but I feel that my case is not clear enough and, as I said, it of high importance to me. I now realize that perhaps it is not as simple as I thought so I will try and raise the point value to 250.

Pavel - My application is not multimedia, I am aware that 4ms may be a stretch, but as I said, even if, at times, the tick will occur after 50ms, it is still fine.

LMiller - I was hoping that as the part of my app that is waiting for the clock is working as a seperate thread, that would make it OK.

If anyone can tell me that it is not the case, and placing my code in a separate thread does not solve the problem, I'd be grateful.

If you are talking about 50msec time interval, you can use your approach. You need to use GetTickCount, for example, and count how long is your timer handling procedure. If it takes longer than 50msec, optimize the code.

Windows is not a real time operating system. No thread has any assurances of how much CPU time it will receive or how often it will have control of a CPU core. It seems clear that the thread handling messages is overburdened and cannot keep up. I think you must solve the problem with an approach that does not involve such a high rate of timer messages.

if your app can actually raise a event every 4 msecs,
which i agree, shouldn't be a problem

but what does the event trigger ?
slow code ? fast code ? starting a thread ?
just running some code in the vcl foreground ?
what does the triggered code actually do ?