Quasi real time con windows - Cronologia

Qualivision il 10:29, 28 giu 2019

2019-06-28T10:29:47Z

Qualivision il 15:44, 27 giu 2019

2019-06-27T15:44:11Z

Qualivision il 15:42, 27 giu 2019

2019-06-27T15:42:38Z

Qualivision il 15:14, 21 giu 2019

2019-06-21T15:14:15Z

Qualivision: /* = */

2019-06-21T15:13:41Z

‎=

Qualivision: /* = */

2019-06-21T15:09:53Z

‎=

Qualivision: /* = */

2019-06-21T15:09:26Z

‎=

Qualivision: /* = */

2019-06-21T15:09:03Z

‎=

Qualivision: /* = */

2019-06-21T15:08:53Z

‎=

Qualivision: /* = */

2019-06-21T15:08:30Z

‎=

← Versione meno recente		Versione delle 10:29, 28 giu 2019
Riga 22:		Riga 22:

	task3.Start();		task3.Start();
		+
		+
		+	'''5)''' Il compilatore, JIT o il processore possono riordinare le operazioni di memoria per ottimizzare la performance.
		+	Questo è negativo quando per esempio ci serve assegnare in una determinata sequenza delle variabili.
		+
		+	Per evitare questo problema si possono usare le memory barrier.
		+	Ogni assegnazione che si trova prima del memory barrier non verrà effettuata dopo di esso, però l'ordine in cui vengono eseguite le assegnazioni prima del memory barrier potrebbe non essere rispettato.
		+	x = 1;
		+	y = 2;
		+	z = 3;
		+	Thread.MemoryBarrier();
		+	k = 4;
		+
		+
		+	In questo esempio le assegnazioni possono avvenire in questo ordine:
		+
		+	x ➡ y ➡ z ➡ k
		+
		+	x ➡ z ➡ y ➡ k
		+
		+	y ➡ x ➡ z ➡ k
		+
		+	y ➡ z ➡ x ➡ k
		+
		+	z ➡ x ➡ y ➡ k
		+
		+	z ➡ y ➡ x ➡ k
		+
		+
		+	k non verrà mai assegnata prima di x, y e z, ma l'ordine in cui x, y e z vengono assegnate varia.

← Versione meno recente		Versione delle 15:44, 27 giu 2019
Riga 6:		Riga 6:
	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.		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, ma si parla di 1-2 ms. Questo vale anche per gli algoritmi di Halcon o altro che usano un timeout. ~~Tantomeno della misura fatta con strumenti come~~ lo stopwatch.	+	'''1)''' Windows non misura bene il tempo, ma si parla di 1-2 ms. Questo vale anche per gli algoritmi di Halcon o altro che usano un timeout. Ovviamente anche lo stopwatch del C#.

@@ Riga 6: / Riga 6: @@
 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.
+'''1)''' Windows non misura bene il tempo, ma si parla di 1-2 ms. Questo vale anche per gli 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.
+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. Facendo riferimento al punto 1, meglio avere 1-2 ms di incertezza leggendo uno stopwatch in un ciclo whicle 'attivo' ossia senza sleep.
-'''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#.
+'''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#. Dai 2-3 ms in su.

@@ Riga 1: / Riga 1: @@
-Decalogo del programmatore di applicazione "quasi real time" in ambiente Windows.
+Nozioni per programmare applicazioni "quasi real time" in ambiente Windows.
-SUCAMELO
+------------------------------------------------------------------------------------
 Scritto nel periodo in cui lavoriamo con Windows 10 IoT LTSC

@@ Riga 1: / Riga 1: @@
 Decalogo del programmatore di applicazione "quasi real time" in ambiente Windows.
-=================================================================================
+SUCAMELO
 Scritto nel periodo in cui lavoriamo con Windows 10 IoT LTSC

@@ Riga 19: / Riga 19: @@
-var task3 = new Task(() => MyLongRunningMethod(),
+var task3 = new Task(() => MyLongRunningMethod(), TaskCreationOptions.LongRunning | TaskCreationOptions.PreferFairness);
-                    TaskCreationOptions.LongRunning | TaskCreationOptions.PreferFairness);
 task3.Start();

@@ Riga 7: / Riga 7: @@
 ) 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.
 ) 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.
 ) Se in task (C#) va in eccezione può rallentare tutti gli altri task. Sembra assurdo ma lo abbiamo replicato con un semplice programma C#.
 ) Al task sarebbe meglio dare l'opzione "longRunning" così ogni task ha il suo thread e non sono tutti in un pool di thread:

← Versione meno recente		Versione delle 15:08, 21 giu 2019
Riga 10:		Riga 10:
	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.		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#.		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();