Che cosè un blocco della memoria?

Storicamente, tutti i programmi per computer sono stati scritti in modo assolutamente sequenziale. Questo è semplice da leggere, scrivere e capire. È anche semplice da eseguire per un computer e richiede un hardware relativamente semplice. Con questo paradigma di progettazione, gli unici due modi per aumentare le prestazioni del sistema sono scrivere codice più efficiente e aumentare la velocità della CPU. Potrebbe essere possibile aumentare l'efficienza del codice, ma in genere si tratta di un processo complesso con risultati spesso limitati.

Per decenni, le prestazioni potrebbero essere ridotte in attesa di CPU nuove e più efficienti. Come descritto dalla legge di Moore, le prestazioni delle CPU raddoppiano all'incirca ogni due o tre anni. Sfortunatamente, la maggior parte di questi miglioramenti delle prestazioni derivava dall'utilizzo di nodi di produzione sempre più piccoli. La tecnologia moderna ha lottato per ridurre le dimensioni dei nodi al ritmo storico, grazie alle difficoltà materiali che lavorano alla scala dei nanometri.

Per aggirare questo problema, i moderni architetti di CPU hanno scelto di aggiungere più core di processore alle CPU. Ogni core del processore può agire in modo indipendente su un'attività diversa. Sebbene non possano combinare lo stesso problema, possono lavorare su due problemi contemporaneamente. Questa fondamentale modifica dell'architettura fornisce molte prestazioni extra, ma non avvantaggia direttamente i singoli processi, sebbene riduca la contesa per il tempo del processore.

Per sfruttare le CPU multi-core, il codice deve essere scritto in modalità multi-thread. Ogni thread può quindi essere eseguito contemporaneamente, ridimensionando il vantaggio in termini di prestazioni in base al numero di thread disponibili e core della CPU. Fare questo, però, si imbatte in una nuova sfida, la "condizione di gara".

Nota: alcune attività non possono essere multi-thread, mentre altre possono essere multi-thread in modo massiccio. I possibili vantaggi in termini di prestazioni dipendono dal lavoro svolto.

Condizioni di gara

Il software multi-thread può sfruttare più core. I pericoli sono in agguato in quelle acque, pronti a intrappolare il programmatore inesperto. Una race condition può verificarsi quando due thread diversi interagiscono con lo stesso bit di memoria.

Un semplice esempio potrebbe essere due thread che tentano di controllare e incrementare una variabile contemporaneamente. Diciamo che a=0 . Due thread diversi quindi eseguono le loro funzioni e, a un certo punto, controllano a e lo incrementano di uno. In genere, ti aspetteresti che il risultato di due thread che aggiungono uno a zero sia due. Il più delle volte, dovrebbe essere così. Puoi ottenere un risultato diverso se entrambi i thread passano attraverso quella specifica funzionalità esattamente al momento giusto.

In questo caso, il primo thread legge il valore di a . Prima che il primo thread possa incrementare il valore di un pensiero, il secondo thread lo legge. Ora il primo thread aggiunge uno a zero, ma il secondo thread crede già che il valore sia zero, aggiungendo uno a zero. Il risultato è che il valore finale di a è 1, non 2.

Corsa allo scenario peggiore

Anche se l'esempio sopra potrebbe non suonare particolarmente male, può avere effetti drammatici. Cosa succede se il valore di a seleziona la modalità di funzionamento di una macchina? E se specifiche modalità di funzionamento di quella macchina possono essere pericolose o addirittura pericolose per la vita?

Anche le condizioni di gara non devono essere così semplici. Ad esempio, può essere possibile che un thread legga una sezione di memoria nello stesso momento in cui un altro thread vi scrive. In questo caso, il thread di lettura potrebbe ottenere uno strano mix di dati sia prima che dopo. Diciamo che il controllo è un semplice controllo vero/falso.

Se la variabile diceva true all'inizio della lettura ma era in procinto di essere sovrascritta nella parola false, il risultato dell'operazione di lettura potrebbe essere qualcosa come "trlse". Questo non è "vero" o "falso". Non essere nessuna delle due opzioni in una scelta binaria comporterebbe quasi certamente l'arresto anomalo dell'applicazione. Questo danneggiamento della memoria può portare a molti problemi di sicurezza, come la negazione del servizio e l'escalation dei privilegi.

Bloccare la corsa

Sapere quali bit di memoria in un programma sono condivisi tra diversi thread è essenziale per prevenire una race condition. Non è necessario fare nulla se una variabile è sempre e solo controllata e accessibile da un singolo thread. Se due o più thread possono accedere a una variabile, allora devi assicurarti che tutte le operazioni su quel pezzo di memoria siano completate indipendentemente l'una dall'altra.

Questa indipendenza si ottiene grazie a una serratura. Nel codice di un programma, devi mettere un lucchetto quando scrivi una funzione che opera su un pezzo di memoria condiviso. Questo blocco impedisce ad altri thread di accedere a quella parte di memoria fino a quando il blocco non viene rilasciato.

La serratura non è la più elegante delle soluzioni. Per prima cosa, ha un sovraccarico di memoria. Può anche forzare il blocco di un thread, in attesa del rilascio di un blocco. A seconda della situazione, il blocco potrebbe non essere rilasciato per molto tempo o potrebbe non essere rilasciato affatto. Nello scenario peggiore, lo sblocco di un blocco potrebbe dipendere da qualcosa che accade in un altro thread bloccato, portando a un deadlock.

È fondamentale ottimizzare l'utilizzo delle serrature. Puoi controllare quanto è granulare il blocco. Ad esempio, se stai modificando i dati in una tabella, puoi bloccare l'intera tabella o bloccare solo la riga modificata. Il blocco dell'intera tabella sarebbe un blocco di granularità grossolana. Riduce al minimo il sovraccarico derivante dall'implementazione di troppi blocchi, ma aumenta la possibilità che un altro thread venga bloccato dal blocco. Bloccare solo la riga sarebbe un bel blocco di granularità. È molto meno probabile che interferisca con altri thread, ma significa che saranno necessari blocchi strappati, aumentando l'overhead totale.

Conclusione

Un blocco della memoria è uno strumento di codice utilizzato per garantire l'atomicità delle operazioni in memoria in un ambiente multithread. Bloccando un pezzo di memoria prima di operare su di esso, puoi essere certo che non si verifichino comportamenti imprevisti a causa di una race condition. I blocchi di memoria comportano un sovraccarico della memoria, ma possono anche causare il blocco.

Il blocco è il punto in cui un altro thread tenta di operare su una memoria bloccata. Il filo si trova lì, bloccato fino a quando il blocco non viene rilasciato. Ciò può causare problemi se il rilascio del blocco richiede che un altro thread esegua un'operazione, poiché potrebbe bloccarsi prima che possa completare il prerequisito per rilasciare il blocco che lo blocca. I blocchi di memoria possono essere evitati scrivendo codici non bloccanti. Farlo, tuttavia, può essere complesso e meno performante rispetto all'utilizzo dei blocchi. Non dimenticare di lasciare i tuoi commenti qui sotto.