了解多媒体定时器的奇怪行为

Question

I am using Multimedia timers in my application (C# .NET) to increase accuracy of my timer and to achieve 1 ms timer frequency. My application had been working great so far until recently it started behaving strangely. I am trying to understand what is wrong with my application. Below are the steps taken

1. timer frequency is set to 1 ms, callback is called on every 1ms
2. there are 4 threads, each creating its own timer object. They all are set to call the callback after 1ms. These are individual instances and not shared.
3. old piece of code execution time was about 0.3 ms. This was working fine until next step.
4. application code is changed. Timer callback function now takes about 1.2 ms for execution. This is clearly a problem. (I am going to work on optimizing the code later. But now I just want to understand the multimedia timer behavior)
5. only the 1st thread is calling the timer callback where as for other threads the call back is called only twice or thrice and after that the callback is never called.
6. Looks like for other threads, the timer even is missed (?) and it cannot catch up. (Its missed for every interrupt).

Could you please explain me the behavior of the timer objects. Are all the threads actually pointing to same timer object since its a single process? Why are other threads not calling the timer callback?

Answer 1

The maximum resolution for the Multimedia timer is 1ms. This causes the programmable interrupt controller (on the hardware) to fire every 1ms. If you fire up 4 threads that all create timers which have 1ms timings that does not mean you will get events more than once per millisecond.

I encourage you to read the Why are the Multimedia Timer APIs (timeSetEvent) not as accurate as I would expect? blog post on MSDN.

Some quotes that are applicable here (emphasis mine):

The MM Timer APIs allow the developer to reprogram the Programmable Interrupt Controller (PIC) on the machine. You can specify the new timer resolution. Typically, we will set this to 1 millisecond. This is the maximum resolution of the timer. We can't get sub-millisecond accuracy. The effect of this reprogramming of the PIC is to cause the OS to wake up more often. This increases the chances that our application will be notified by the operating system at the time we specified. I say, “Increases the chances” because we still can't guarantee that we will actually receive the notification even though the OS work up when we told it.

And:

Remember that the PIC is used to wake up the OS so that it can decide what thread should be run next. The OS uses some very complex rules to determine what thread gets to occupy the processor next. Two of the things that the OS looks at to determine if it should run a thread or not are thread priority and thread quantum.

So, even if you put the resolution down to the maximum of 1ms, you are not guaranteed that your thread will be the one chosen to do its work.

Answer 2

I suppose that you use a system timer that runs callbacks on a single dedicated thread.

Then you set the system interval to 1 ms. And before your change the callback takes 0.3 ms to complete, so the callbacks of the 4 threads take 4 * 0.3 = 1.2 ms to complete. So they manage to complete on 1-2 time intervals, and can all start again after that.

But after your change each callback takes 1.2 ms itself. So we have requests to run callbacks from the threads 2-4 and another request from thread 1 (because the time interval ran out). After that it depends on the timer used, which request it will serve. It turns out, that the one from the first thread.