pthreads v. SSE debole ordine di memoria

Question

Le funzioni pthread di glibc di Linux su x86_64 fungono da recinzioni per accessi di memoria debolmente ordinati? (pthread_mutex_lock/unlock sono le funzioni esatte a cui sono interessato).

SSE2 fornisce alcune istruzioni con ordini di memoria deboli (negozi non temporali come movnt in particolare). Se stai usando queste istruzioni e vuoi garantire che un altro thread/core veda un ordinamento, allora capisco che hai bisogno di una recinzione esplicita per questo, ad es. Un'istruzione di sfence.

Normalmente ci si aspetta che l'API pthread funga da recinzione in modo appropriato. Tuttavia, sospetto che il normale codice C su x86 non generi accessi di memoria debolmente ordinati, quindi non sono sicuro che i pthreads debbano agire come una barriera per accessi debolmente ordinati.

Leggendo attraverso il codice sorgente plyread di glibc, un mutex viene alla fine implementato usando "lock cmpxchgl", almeno sul percorso non indirizzato. Quindi immagino che quello che ho bisogno di sapere è che le istruzioni fungono da recinto per gli accessi debolmente ordinati SSE2?

Answer 1

I magazzini non temporali necessitano dell'ordinazione sfence da ordinare correttamente.

Tuttavia, l'implementazione a livello utente efficiente di un mutex semplice presuppone che venga rilasciata da una semplice scrittura che non implica il flush dei buffer di scrittura, al contrario delle operazioni di lettura-modifica-scrittura atomiche come lock cmpxchg che implicano la memoria piena recinzione.

Quindi si ha una situazione in cui il unlock non ha effetto della semantica store-with-release applicata per i negozi non temporali. Pertanto, questi archivi SSE possono essere riordinati dopo lo sblocco e dopo un altro thread acquisisce il mutex.