Benvenuto a questo nuovo articolo della serie labVIEW.
Parliamo di Variabili locali e Globali che spesso sono iperutilizzate dai neofiti o addirittura messe al bando dagli sviluppatori più zelanti.
In labview il modello primario di programmazione è il data flow.
Il flusso di dati garantisce sincronismo nell’esecuzione dei nodi.
La programmazione parallela prevede l’esecuzione di thread o processi in modo asincrono, quindi un esecuzione indipendente e autonoma tra loro.
Per comunicare dati tra processi paralleli, esistono diversi metodi.
Un primo metodo è l’utilizzo di variabili locali e globali.
Variabili Locali
Sono una memoria implicitamente collegata a un controllo o indicatore.
Sono locali in quanto associate ad oggetti del Front Panel e quindi localmente al vi.
Possono scrivere o leggere il valore di un controllo o un indicatore programmaticamente.
Sono comode e facili da implementare, questo spesso ne crea un abuso nell’utilizzo.
Il problema principale nasce da unaperdita di leggibilità e manutenibilitá del codicee quando abbiamo più di una variabile utilizzata in scrittura, si può verificare unarace condition o accesso concorrente.
Altro problema è il collegamento implicito, che crea unincompatibilità con la mechanical action“latch” dei boolean, limitando l’usabilità del Front Panel, a meno di meccanismi old style.
Non possiedono un meccanismo disincronizzazione.
Ma allora le local sono da evitare? Cosa dovrei utilizzare?
Non sono da evitare, ma circoscriverne l’utilizzo a compiti comeinizializzare e scrivere programmaticamente su un controllo, mentre gli indicatori possono essere aggiornati con il data flow o altri metodi che possano fornire anche sincronizzazione tra loop paralleli.
Variabili Globali
Le variabili Globali, sono memorie dichiarate su file per cui le istanze sono esplicite ai controlli dell’interfaccia e sono condivisibili tra diversi vi.
Questo risolve il problema della incompatibilità per i boolean di tipo latch. Il che utilizzati in modalità 1wMr (1scrittore Molti lettori) possono essere comode cometagper leggere il valore di un controllo da un processo su un altro processo. Esempio: un loop scrive la variabile da un controllo di stop e gli altri loop leggono il valore della variabile che setta anche la loop condition, sincronizzando la chiusura dei processi.
Anche in questo caso quindi non si risolve la race condition, ne il sovrautilizzo che genera perdita di leggibilità e manutenibilitá.
Polling
Questo tipo di sincronismo inoltre avviene sul dato, quindi non fornisce un utilità di notifica o evento, costringendo sl polling programmatico(devo leggere sempre lo stato per capire se è successo qualcosa).
