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 una perdita di leggibilità e manutenibilitá del codice e quando abbiamo più di una variabile utilizzata in scrittura, si può verificare una race condition o accesso concorrente.
Altro problema è il collegamento implicito, che crea un incompatibilità con la mechanical action “latch” dei boolean, limitando l’usabilità del Front Panel, a meno di meccanismi old style.
Non possiedono un meccanismo di sincronizzazione.
Ma allora le local sono da evitare? Cosa dovrei utilizzare?
Non sono da evitare, ma circoscriverne l’utilizzo a compiti come inizializzare 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 come tag per 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).
