Funktionieren die Linux glibc pthread-Funktionen auf x86_64 als Zäune für schwach geordnete Speicherzugriffe? (pthread_mutex_lock / unlock sind genau die Funktionen, die mich interessieren).
SSE2 liefert einige Anweisungen mit schwacher Speicherordnung (nicht-zeitliche Speicher wie insbesondere movntps). Wenn Sie diese Anweisungen verwenden und sicherstellen möchten, dass ein anderer Thread / Kern eine Bestellung sieht, dann verstehe ich, dass Sie dafür einen expliziten Zaun benötigen, z. B. eine sfence-Anweisung.
Normalerweise erwarten Sie, dass die Pthread-API entsprechend als Zaun fungiert. Ich vermute jedoch, dass normaler C-Code auf x86 keine schwach geordneten Speicherzugriffe erzeugt, daher bin ich nicht sicher, dass Pthreads als Zaun für schwach geordnete Zugriffe dienen muss.
Beim Lesen des glibc pthread-Quellcodes wird ein Mutex am Ende mit "lock cmpxchgl" implementiert, zumindest auf dem unbetonten Pfad. Ich vermute also, dass das, was ich wissen muss, ist, dass diese Anweisung als Zaun für schwach geordnete SSE2-Zugriffe dient?
Nicht-temporale Speicher müssen sfence -Anweisung ordnungsgemäß bestellt werden.
Die effiziente Implementierung eines einfachen Mutex auf Benutzerebene setzt jedoch voraus, dass sie durch ein einfaches Schreiben freigegeben wird, was im Gegensatz zu atomaren Lese-Modifizier-Schreib-Operationen wie lock cmpxchg , die auf voll implizieren, nicht zu Schreibpuffern führt Speicherzaun.
Sie haben also eine Situation, in der unlock keinen Effekt von store-with-release Semantik hat, die auf nicht-temporale Speicher angewendet wird. Somit können diese SSE-Speicher nach dem Entsperren neu geordnet werden und nachdem ein anderer Thread den Mutex erwirbt.
Tags und Links multithreading sse pthreads atomic memory-fences