alex.moskalyuk

Memi asks about using .NET for real-time apps. Naturally, that depends on what kind of application you’re writing and what is meant by real-time. Without direct way to access CPU interrupts, dealing with direct memory access (even though it’s not really direct, but you know what I mean, shuffling the data between the registers, level 1 and level 2 caches and RAM chips) and assigning interrupt priority you’re not given a lot of comfort to deal with real-time. It’s more like being asked to play soccer, but then being told that you can only do this in a tuxedo you’re not allowed to smirch, blind-folded and in a wheel chair.

Also, some things are not working exactly as advertised for the app to be considered a truly real-time. Let’s take System.Windows.Forms.Timer, for example. The description of the class and the ability to pass the number of the milliseconds to the timer looks pretty good, although with gigahertz CPUs you should be able to control microseconds, which you do, if you step down to superfun Assembly stuff (oh, but Assembly ties you to Intel x86 and hardware-dependent, but wait a minute - so does .NET Framework). But after you’re sort of satisfied with the behavior, you google additionally and come up with this nice MSDN article on timers.

Several quotes from there:

Even though you can technically set the Interval property as low as one millisecond, you should be aware that the .NET Framework documentation states that this property is only accurate to approximately 55 milliseconds.

It doesn’t mention that, actually (I just did a search in .NET Framework documentation for 55, found a lot of other places where the number was used, but nothing specific to the Timer behavior, maybe the wrong set of docs), but still, here you have to re-define your understanding of real-time once again. And earlier before the author of the article actually tells you that System.Windows.Forms.Timer is probably the least appropriate candidate for real timing (the rest of the guys aren’t superb either):

If you’re looking for a metronome, you’ve come to the wrong place. The timer events raised by this timer class are synchronous with respect to the rest of the code in your Windows Forms app. This means that application code that is executing will never be preempted by an instance of this timer class (assuming you don’t call Application.DoEvents).

I suspect things might be done differently for the XP Embedded world, where things like interrupt priorities and microsecond timers might be important for some device manufacturers out there.