Quasi real time con windows

Decalogo del programmatore di applicazione "quasi real time" in ambiente Windows. SUCAMELO

Scritto nel periodo in cui lavoriamo con Windows 10 IoT LTSC

Tutto questo vale se si lavora con tempi molto ristetti, per esempio un algoritmo deve compiere tutta la sua elaborazione in 50 ms e ritardi dell'ordine dei 5-10 ms iniziano ad essere significativi.

1) Windows non misura bene il tempo. Non fidarsi degli algoritmi di Halcon o altro che usano un timeout. Tantomeno della misura fatta con strumenti come lo stopwatch.

2) Un comando di pausa/sleep o simili in un ciclo ha effetti devastanti: una sleep di 1 ms potrebbe aspettare 10 ms o oltre. Questo è stato testato non solo con un programma C# ma anche con HDevelop e Sherlock. Una sleep in un ciclo abbassa la resa del task/thread in cui gira. L'unica alternativa per andare veloci è un ciclo senza sleep che va al massimo, userà tutta la CPU ma gira molto basso, sul vecchio PC laboratorio, testato con l'oscilloscopio andava a 130 microsecondi.

3) Se in task (C#) va in eccezione può rallentare tutti gli altri task. Sembra assurdo ma lo abbiamo replicato con un semplice programma C#.

4) Al task sarebbe meglio dare l'opzione "longRunning" così ogni task ha il suo thread e non sono tutti in un pool di thread:

var task3 = new Task(() => MyLongRunningMethod(), TaskCreationOptions.LongRunning | TaskCreationOptions.PreferFairness);

task3.Start();