Quale modello di memoria è implementato in .NET Core?

La specifica CLI ECMA definisce un modello di memoria debole. Ciò consente di riordinare l'ordine di esecuzione del comando (utile per le prestazioni). Ma scrivere un codice di basso livello per un tale modello è molto difficile.

E, soprattutto, le architetture del processore X86 / AMD64 hanno un modello di memoria più rigoroso (forte). Di conseguenza, Microsoft ha implementato un modello di memoria più forte nella sua implementazione CLR rispetto a quanto descritto nelle specifiche.

Il modello di memoria è cambiato in .NET Core? Potenzialmente, questo framework può essere eseguito su architetture con un modello di memoria più debole rispetto a X86 / AMD64.

Inoltre, .NET Core incorpora Mono e altri. E per quanto ne so, il modello di memoria Mono è più debole, corrisponde all'ECMA.

In questo articolo Presentazione di .NET 5 scritto:

Espandi le funzionalità di .NET sfruttando il meglio di .NET Core, .NET Framework, Xamarin e Mono.

Quindi penso che se non ora, in futuro questi runtime si fonderanno in un unico insieme.
Di seguito nell'articolo è scritto:

Stiamo effettuando sostituzioni drop-in CoreCLR e Mono l'una per l'altra. Renderemo semplice quanto un interruttore di generazione per scegliere tra le diverse opzioni di runtime.

Se capisco correttamente, ci saranno due (o più) tempi di esecuzione. E probabilmente ognuno avrà il proprio modello di memoria.

Di cosa stiamo parlando: modello di memoria .

Il modello di memoria è specifico per il runtime, quindi la tua domanda è in realtà "ci sono differenze nei modelli di memoria di CLR, CoreCLR e MonoRuntime".

Dopo aver studiato un po ', la domanda è davvero, molto difficile a cui rispondere. C'è la specifica ECMA che hai citato, che ti offre le garanzie minime che tutte le implementazioni devono fornire. C'è una descrizione molto concisa e concisa sul blog di Joe Duffy per CLR 2.0. Quindi, per .NET Framework c'è questo articolo in due parti che parla del modello CLR in probabilmente più dettagli di quanti ne sappiano. C'è persino un documento scritto su questo.

Per MonoRuntime, ho trovato questo documento che parla di atomica e in realtà descrive il modo in cui Mono lo implementa, sebbene il livello di dettaglio sia piuttosto basso.

Trovare i dettagli di CoreCLR è ancora più complicato. Ci sono alcuni punti chiave evidenziati in questo thread GitHub dotnet / coreclr e una discussione su letture / scritture volatili in questo .

Il modo più semplice di rispondere è: sì, è cambiato, in base alle risorse di cui sopra.

Tuttavia, c'è un secondo modo di rispondere alla tua domanda e quello di negare semplicemente la sua premessa - sembra supporre che il modello di memoria sia cambiato nel senso che alcune persone intelligenti si sono sedute, riscritto le specifiche della CLI dell'ECMA, trasformandolo nel CoreCLR specifiche del modello di memoria e questo è il nuovo modello di memoria. Questo non è il caso. Le persone intelligenti menzionate si sono sedute e, nel corso di molti mesi, hanno perfezionato il design in modo che fosse affidabile, veloce, sensibilmente facile da implementare e non in violazione delle garanzie minime delle specifiche. Citando dal blog di Joe Duffy collegato:

Abbiamo costruito il nostro modello nel corso di anni di lavoro informale e design-by-example (...) che è suscettibile di passare da un'implementazione alla successiva.

La specifica informale ECMA è, purtroppo, formale come possiamo ottenere per ora. Non esiste una descrizione formale delle modifiche tra le specifiche ECMA e l'implementazione del CLR, né esiste una descrizione formale delle modifiche tra CLR e CoreCLR. E, cosa ancora più importante, le differenze specifiche di implementazione tra CLI ECMA e CLR / CoreCLR sono proprio queste - specifiche dell'implementazione - e non devono essere invocate . L'unica fonte affidabile al 100% di come viene implementato il modello di memoria .NET Core è il codice sorgente. E questo ovviamente cambia con ogni commit, ogni release, e non vi è alcuna garanzia che il team non getti l'intero jitter fuori dalla finestra e lo riscriva per .NET 5 in modo che sia esattamente uguale alle specifiche ECMA (per quanto selvaggiamente improbabile sia ).