16

This is a bit of an academic question as I'm struggling with the thinking behind Microsoft using double as the data type for the Interval property!

Firstly from MDSN Interval is the time, in milliseconds, between Elapsed events; I would interpret that to be a discrete number so why the use of a double? surely int or long makes greater sense!?

Can Interval support values like 5.768585 (5.768585 ms)? Especially when one considers System.Timers.Timer to have nowhere near sub millisecond accuracy... Most accurate timer in .NET?

Seems a bit daft to me.. Maybe I'm missing something!

Community
  • 1
  • 1
Dave Lawrence
  • 3,843
  • 2
  • 21
  • 35
  • Have you tried it? Have you used one of the disassembler tools to see how non-integral values are processed to the underlying Win32 API? – Richard Jul 23 '12 at 10:25
  • Doesn't make much sense to me. Reasonable choices would have been `int` or `TimeSpan`. – CodesInChaos Jul 23 '12 at 10:27
  • @Richard, are you implicitly trying to give me an answer? I'm not sure why I should have to do such a thing? Is the double value a result of a type constraint on the Win32 API? – Dave Lawrence Jul 23 '12 at 10:33
  • I suspect that might be the case, but I don't know it (and thus I'm not trying to lead you to an answer I already know). More a question of: have you tried to find out the answer yourself? – Richard Jul 23 '12 at 13:02

2 Answers2

13

Disassembling shows that the interval is consumed via a call to (int)Math.Ceiling(this.interval) so even if you were to specify a real number, it would be turned into an int before use. This happens in a method called UpdateTimer.

Why? No idea, perhaps the spec said that double was required at one point and that changed? The end result is that double is not strictly required, because it is eventually converted to an int and cannot be larger than Int32.MaxValue according to the docs anyway.

Yes, the timer can "support" real numbers, it just doesn't tell you that it silently changed them. You can initialise and run the timer with 100.5d, it turns it into 101.

And yes, it is all a bit daft: 4 wasted bytes, potential implicit casting, conversion calls, explicit casting, all needless if they'd just used int.

Adam Houldsworth
  • 63,413
  • 11
  • 150
  • 187
  • My _guess_ is that the resolution of the timer could theoretically improve in the future (to less than a millisecond) and they were just future-proofing it. Maybe it was just a mistake way back in 1.1 and rather than make it a breaking change they just carried it over. – Chris Sinclair Jul 23 '12 at 11:00
  • @ChrisSinclair Possibly, but when you go trawling through the implementation, it all hangs off of `System.Threading.Timer` which in turn uses an unmanaged timer (I think). It all boils down to using `uint`. All of this makes it even more strange as to why `double` was chosen, as the base classes don't use it at all. – Adam Houldsworth Jul 23 '12 at 11:16
  • @both: int at 100ns resolution does not fully resolve the timers capabilities. See my answer below. – Arno Jul 24 '12 at 18:22
5

The reason to use a double here is the attempt to provide enough accuracy.

In detail: The systems interrupt time slices are given by ActualResolution which is returned by NtQueryTimerResolution(). NtQueryTimerResolution is exported by the native Windows NT library NTDLL.DLL. The System time increments are given by TimeIncrement which is returned by GetSystemTimeAdjustment().

These two values are determining the behavior of the system timers. They are integer values and the express 100 ns units. However, this is already insufficient for certain hardware today. On some systems ActualResolution is returned 9766 which would correspond to 0.9766 ms. But in fact these systems are operating at 1024 interrupts per second (tuned by proper setting of the multimedia interface). 1024 interrupts a second will cause the interrupt period to be 0.9765625 ms. This is of too high detail, it reaches into the 100 ps regime and can therefore not be hold in the standard ActualResolution format.

Therefore it has been decided to put such time-parameters into double. But: This does not mean that all of the posible values are supported/used. The granularity given by TimeIncrement will persist, no matter what.

When dealing with timers it is always advisable to look at the granularity of the parameters involved.

So back to your question: Can Interval support values like 5.768585 (ms) ?

No, the system I've taken as an example above cannot.

But it can support 5.859375 (ms)!

Other systems with different hardware may support other numbers.

So the idea of introducing a double here is not such a stupid idea and actually makes sense. Spending another 4 bytes to get things finally right is a good investment.

I've summarized some more details about Windows time matters here.

BenMorel
  • 34,448
  • 50
  • 182
  • 322
Arno
  • 4,994
  • 3
  • 39
  • 63
  • Although I'm not going to state that what you say is inaccurate, as far as the `System.Timers.Timer` goes, it doesn't support the `double` at all as it is immediately cast to an `int` after a `Math.Ceiling` call - negating the point of a `double` in this instance. – Adam Houldsworth Jul 24 '12 at 20:07
  • @AdamHouldsworth: Well, it's not that I'm saying everything is correct with all these implementations. It is just impossible to change everything at the same time. So the front end (System.Timers.Timer) interval property has received a reasonable format, which may survive for a long time. But: Underlaying software has to treat this exetended accuracy correctly to reach better results. Thanks for showing that this is not yet done correctly. So it needs some more work to get things right. – Arno Jul 25 '12 at 08:27
  • +1 for providing the logic for an actual reason. The question is asking for a reason and the accepted answer has not provided one. Implementations of methods change at every update and it may be that they are indeed planning to use something lke that in the future. – ThunderGr Nov 29 '12 at 05:37