Un'azione atomica dovrebbe essere deterministica?

Qual è la proprietà "al massimo una volta"? Se stai discutendo la definizione di un termine, penso che sarebbe molto utile fornirlo.

Per quanto ho capito, si suppone che un'azione atomica garantisca che solo due degli stati possibili siano osservabili: o l'azione viene eseguita o non lo è. L'operazione non è divisibile . Questo è supportato dalla pagina su Wikipedia .

Mi sembra che tu stia facendo una supposizione nel tuo post che alcune operazioni aritmetiche o logiche sono atomiche, ma in condizioni generali questa ipotesi è falsa.

Se condividi le variabili su più thread senza la sicurezza del thread, avrai un brutto periodo di determinazione.

Primo piano. Le azioni atomiche sono deterministiche per se stesse.

x = y + 1, ti darà sempre il valore di y +1, qualunque cosa tu sia al momento dell'esecuzione . A livello di sistema, il risultato di questa affermazione è una possibile condizione di competizione dovuta all'aggiornamento in un thread diverso.

Questo non è tecnicamente un caso di "non determinismo", come sarebbe se tu dovessi fare x = y + 1 * rand () (senza usare un seme impostato). Questa è una condizione di gara più dritta perché stai facendo ipotesi sullo stato delle variabili che potrebbero essere o non essere corrette.

La realtà di questa situazione è "non farlo". Non usare variabili condivise tra thread. Copia le informazioni di input in thread, copia le informazioni. Assicurati sempre che i tuoi thread abbiano i dati necessari per svolgere il loro lavoro e assicurati che non debbano mai raggiungere il loro spazio di discussione locale per farlo.

Se hai assolutamente e assolutamente bisogno di colpire dati condivisi, devi usare le primitive di sincronizzazione, ma rende le cose molto più semplici se adotti un paradigma in cui i thread non colpiscono la memoria condivisa se non per depositare i risultati.

E a quel punto puoi usare cose come code senza serratura e altri meravigliosi frammenti per evitare l'intera procedura di blocco / sblocco.

A scopo informativo. se devi assolutamente condividere y tra i thread. Suggerirei di utilizzare un blocco di scrittura in stile gate per bloccare l'accesso a y mentre viene scritto dall'altra thread. tutte le altre volte sarete in grado di leggere immediatamente poiché il cancello sarebbe "aperto" ai lettori.

Sì e no.

Sì, un'azione atomica dovrebbe sempre produrre lo stesso risultato dato gli stessi input.

No, un insieme di azioni atomiche, eseguite in parallelo, non produrranno necessariamente lo stesso risultato complessivo. Quando i passaggi sono eseguiti in parallelo, l'input (s) di un particolare passaggio può variare, nel qual caso il suo output (s) può cambiare di conseguenza.

Le azioni atomiche sono necessarie ma non sufficienti per produrre risultati deterministici.

Non c'è un ordine garantito con il multithreading, y = y + 1 può essere eseguito prima o dopo x = y + 1 , che cambierebbe il risultato.

L'atomicità evita qualsiasi stato "intermedio" in una variabile. Ad esempio, se y è lungo 64 bit su un sistema a 32 bit, impostarlo su un valore non è atomico naturale, poiché il processore deve prima impostare i 32 bit inferiori, quindi quelli superiori. Leggere y da un altro thread in quel caso significherebbe che esiste una possibilità di ottenere una versione di y con solo i 32 bit più bassi impostati.

Deterministico non fa parte della definizione di Atomic , in Informatica. È così semplice Questa è una buona cosa; la separazione delle preoccupazioni è importante tanto nelle definizioni CS quanto nella progettazione del software.

Perché vorresti imporre che tutte le azioni atomiche siano deterministiche? Pochissime applicazioni possono essere completamente deterministiche e, mentre è buona pratica isolare le funzioni non deterministiche, cosa otterresti non consentendo loro di essere atomiche?

Atomic deriva dalla parola greca "Atomos" che significa indivisibile. In informatica ciò si riferisce comunemente a un'operazione che può solo avere successo o fallire, o un tipo di dati che può essere letto o scritto senza errori.

In qualsiasi dispositivo sufficientemente complesso, come il regno della programmazione, ci sono un numero qualsiasi di modalità di errore che non vengono prese in considerazione (come improvvise interruzioni di corrente, guasto della RAM ecc.) Ciò significa che qualsiasi tipo di comportamento "atomico" nell'informatica moderna avrà più limiti ben definiti quando si tratta di determinismo. Le CPU moderne di proposito non sempre tengono conto del tempo a causa delle cache, ecc. (Abbiamo timer di interruzione per questo) e questo problema è amplificato come condizioni di gara quando si tratta di interazione con i thread (come nel tuo esempio).

Molti moderni RDB offrono l'illusione pratica di Atomicità usando transazioni su query SQL, queste garanzie sono offerte solo fino a questo punto, che, se è possibile ripristinare le modifiche, il DB lo farà. Se qualsiasi parte del sistema è interrotta, tutte le scommesse sono disattivate.

Naturalmente, è possibile realizzare sistemi hardware e software che potrebbero avvicinarsi a una definizione pura di processi atomici. Pensa al "registratore di scatole nere" in aereo.