I was too afraid to ask in that context what this actually means because I didn't want my coworkers to think I'm stupid.
In realtà, penso che fare domande sia intelligente. È come impari cose che non conosci. E in gruppi più numerosi, è probabile che anche le altre persone non lo sappiano, hanno solo paura di chiedere anche loro.
My understanding of the term "atomic operations" is any operation that is either wholly executed or wholly not executed …
Sì, ma questa è solo una parte. Un'altra parte importante è che l'operazione sembra essere eseguita istantaneamente, ovvero non è possibile osservarla mai in stato di completamento parziale. (Anche se la seguente parte della frase indica che è quello che intendevi.)
… such as in C# with the volatile keyword when setting or getting the value of a primitive, you will definitely never be halfway through getting or setting a volatile primitive when the thread context switches.
Questo non è ciò che volatile
in C # è circa. Impostando il valore di piccoli tipi primitivi (come int
, char
o riferimento, ma non long
o double
) è sempre garantito per essere atomico ( vedere §5.5 Atomicità dei riferimenti variabili delle specifiche C #).
Ciò che volatile
riguarda è l'ordine di accesso ai campi (§10.5.3 Campi volatili della specifica). Normalmente, se scrivi qualcosa come:
this.value = 42;
this.valueIsSet = true;
e quindi osservarlo da un altro thread, quindi potresti vedere valueIsSet
come già true
e value
come ancora 0
, a causa di ottimizzazioni del processore e del processore che riordina le istruzioni. Con volatile
, tale riordino è vietato.
Ciò garantisce anche che il campo venga letto ogni volta, senza volatile
un ciclo come
while (this.shouldRun)
{
// whatever; does not set this.shouldRun
}
potrebbe essere compilato come:
if (this.shouldRun)
{
while (true)
{
// whatever; does not set this.shouldRun
}
}
In ogni caso, usare volatile
correttamente è difficile e dovresti evitarlo a meno che tu non ne abbia davvero bisogno per motivi di prestazioni. La maggior parte delle volte, l'uso di lock e di tipi di libreria thread-safe è sufficiente.
What does this have to do with dynamic vs static typing?
Nessuna idea. Ci sono certamente operazioni atomiche non banali in .Net (come quelle nella classe Interlocked
).
L'unica cosa che posso pensare è che alcune lingue possono usare thread in modalità utente invece di thread nativi, e quindi avere più controllo su quali operazioni sono eseguite atomicamente, perché è il runtime della lingua che decide quando passare i thread. Ma questo non ha nulla a che fare con la digitazione dinamica o statica. (E non ho idea se ci siano linguaggi che in realtà ne traggono vantaggio.)