Se si blocca uno std::mutex otterrò sempre una fence di memoria? Non sono sicuro se ciò implica o ti impone di ottenere il recinto.std :: mutex crea una fence?
Aggiornamento:
trovato questo riferimento seguito alle osservazioni di RMF.
Multithreaded programming and memory visibility
sbloccare un mutex sincronizza con bloccare il mutex. Non so quali opzioni ha il compilatore per l'implementazione, ma ottieni lo stesso effetto di una fence.
quanto ho capito questo è coperto in:
1.10 esecuzioni e le gare di dati multi-threaded
Para 5:
La biblioteca de fi nisce una serie di operazioni atomiche (Clausola 29) e operazioni sui mutex (articolo 30) che sono identi fi cati in modo specifico come operazioni di sincronizzazione. Queste operazioni svolgono un ruolo speciale nel rendere i compiti in un thread visibili a un altro. Un'operazione di sincronizzazione su una o più posizioni di memoria è un'operazione di consumo, un'operazione di acquisizione, un'operazione di rilascio o un'operazione di acquisizione e rilascio. Un'operazione di sincronizzazione senza una posizione di memoria associata è una fence e può essere una fence di acquisizione, una fence di rilascio o una fence di acquisizione e rilascio. Inoltre, ci sono operazioni atomiche rilassate, che non sono operazioni di sincronizzazione, e operazioni di lettura-modifica-scrittura atomiche, che hanno caratteristiche speciali. [Nota: Ad esempio, una chiamata che acquisisce un mutex eseguirà un'operazione di acquisizione sulle posizioni che comprendono il mutex. Corrispondentemente, una chiamata che rilascia lo stesso mutex eseguirà un'operazione di rilascio su quelle stesse posizioni. Informalmente, l'esecuzione di un'operazione di rilascio su A forza gli ef fetti precedenti su altre posizioni di memoria da rendere visibili ad altri thread che eseguono successivamente un consumo o un'operazione di acquisizione su A. Le operazioni atomiche "rilassate" non sono operazioni di sincronizzazione anche se, come le operazioni di sincronizzazione, non possono contribuire alle corse di dati. -end note]
Penso che l'OP chieda di scherma per altre posizioni di memoria diverse dal mutex stesso. – Mysticial
Non capisco. Le recinzioni in C++ non influiscono su posizioni di memoria specifiche. –
Dico questo: Supponiamo che il Core A scriva su "A [0]" e poi rilasci il mutex. Quindi il Core B acquisisce il mutex e legge 'A [0]' (prima che la coerenza della cache possa propagare il nuovo valore di 'A [0]' al core B.) In altre parole, un mutex forza tutte le locazioni di memoria a essere up- fino ad oggi prima di tornare. – Mysticial