Le variabili globali possono essere utilizzate nei programmi asincroni?

Modificare una variabile su un thread e leggerlo su un altro è sempre problematico. La modifica su due thread è peggiore.

Puoi usare le variabili atomiche. Una variabile atomica, ad esempio, garantisce che i lettori ottengano important_var = 0, quindi important_var = 5.0, quindi important_var = 10.0 e così via. Se important_var non è atomico, leggerlo solo quando viene modificato in un altro thread potrebbe produrre qualsiasi risultato .

Il tuo sistema operativo può supportare operazioni atomiche. Il più potente in pratica dice "cambia la variabile x da a a b", che può fallire. Ad esempio invece di aumentare important_var per 5, si dovrebbe lasciare tmp = important_var, quindi "change important_var from tmp to tmp + 5". Se qualcosa cambia important_var in mezzo, l'operazione fallisce e tu prova di nuovo.

Oltre a ciò si usano mutex, code sequenziali o tutti i tipi di meccanismi che evitano di cambiare una variabile mentre vengono cambiati da un altro thread.

Non è tanto il fatto che i globals rendano il codice più difficile da eseguire il debug, anche se se si dispone di un programma molto grande e di uno stato globale che è molto lontano dal suo utilizzo, ciò può avere un effetto negativo.

Il problema con lo stato globale è che è globale, singolare, difficile da estendere.

Pensa a questo, hai alcune variabili che vuoi modificare nelle tue funzioni, così le hai messe da qualche parte dove tutte le funzioni possono condividerle. Immagina che in futuro desideri estendere il tuo programma in modo da poter gestire 2 sistemi affiancati. Hai solo 1 set di stato globale da condividere, quindi non puoi sistemarlo facilmente. Quindi potresti mettere tutto il tuo stato globale in una singola classe e condividerla. Quando si desidera estendere il programma, è ora possibile creare 2 istanze di tale classe, una per ciascun server in esecuzione, rendendo il problema quello di decidere quale oggetto utilizzare per un determinato server.

Ora hai il tuo stato globale in oggetti più localmente detenuti, puoi persino passare quegli oggetti ai server al momento della creazione, isolandoli ulteriormente (è un'iniezione di dipendenza). E ora hai un server che in effetti non usa affatto il globale senza molti cambiamenti nel modo in cui funziona il programma.

Considera questa alternativa, che limita l'ambito di important_var a un singolo file sorgente e incapsula tutto il comportamento importante in una classe in stile C.

important_class.c

static float important_var = 0.0;

void do_important_operation(void)
{
   math.operation(important_var);
}

void do_important_adjustment(float amount)
{
   important_var += amount;
}

bool does_important_condition_exist(void)
{
   return (important_var > 5.0);
}

important_class.h

void do_important_operation(void);
void do_important_adjustment(float amount);
bool does_important_condition_exist(void);

main.c

#include "important_class.h"

void some_synchronous_function(){
   do_something();
   do_important_operation();
}

void do_something(){
   do_important_adjustment(5.0);
}

void async(){
   if(does_important_condition_exist()){
       //whatever
   }
}

main(){
    some_synchronous_function();
}

Probabilmente la tua implementazione va bene per un'applicazione relativamente semplice a cui important_var non è accessibile da troppe posizioni. Ma questa implementazione in stile classe è più robusta ed estensibile e sarà più facile da mantenere man mano che si aggiungono nuove funzionalità e complessità.

Si noti che questa implementazione in stile classe deve ancora essere protetta da thread se più thread e / o ISR chiamano i metodi important_class .