Il modo corretto di gestire la concorrenza in .NET è basato su un modello di memoria debole. Questo non è cambiato in .NET 4.5.
Solo perché Itanium non è più supportato non significa che è possibile assumere i modelli di memoria x86 o amd64 più potenti. Ad esempio, hai altre deboli piattaforme di modelli di memoria, come ARM.
Ricordare sempre che le letture non volatili alla stessa variabile o campo possono essere eliminate dopo il primo dal compilatore JIT, nel caso in cui possa provare che non vi è alcuna sincronizzazione tra le letture (barriere di memoria, blocco monitor di un oggetto che è/era monitorato, lettura volatile di una variabile volatile scritta, operazioni Interlocked su una variabile). Ciò rispetta la coerenza del punto di vista del thread.
L'articolo collegato a mostra esempi in cui il compiler JIT di Microsoft .NET Framework si eleva, ad esempio in. while loop che leggono una variabile non volatile senza alcun punto di sincronizzazione all'interno del ciclo. Ma ricorda, un compilatore JIT potrebbe usare ottimizzazioni di interi programmi per generalizzare questa elisione tra chiamanti e callei.
Come tali, algoritmi lock-free in .NET che leggono una variabile o un campo senza barriere di memoria, blocchi, semantica volatile o operazioni Interlocked, sulla premessa che queste letture alla fine vedranno cambiamenti da altri thread, stanno giocando con il Compilatore JIT In sostanza, questi algoritmi sono sbagliati in termini di portabilità.
Che mi fa chiedere, perché lo chiedi?
viviamo in universi diversi. vale la pena di sapere qui .. forse vale la pena di scrivere applicazioni portatili in .NET nel tuo universo .. Non me ne preoccupo .. sei tu? –
Mi aspetto che alcune delle mie librerie .NET (condivise tra diversi target) funzionino correttamente a 32-bit e 64-bit e in modelli con memoria forte e modelli di memoria deboli. Non sto nemmeno considerando la portabilità al di fuori delle piattaforme Microsoft. Ad esempio, alcuni dei pacchetti NuGet attualmente più popolari (Json.NET, NLog) funzionano sia in Windows Server 2012 R2 (amd64) che in Windows Phone 8.1 o Windows 10 Mobile (possibilmente ARM). E se gli autori non si preoccupassero della portabilità? Non è così difficile ottenere la concorrenza giusta, ciò che è difficile ad es. per ottimizzare, codice refactoring per evitare conflitti, ecc. – acelent
Capisco che, dal tuo punto di vista, potresti mordere il proiettile. Personalmente, preferisco avere il codice pronto per il modello di memoria più debole. Per esempio, comincio a usare i blocchi per ottenere un'implementazione corretta, quindi iterare verso i campi volatili e/o le operazioni "Interlocked". Se decidi di andare con letture non sorvegliate, fallo almeno consapevolmente che "Funziona sul tuo computer". – acelent