Pthread_mutex_t vs. std::atomic_flag Geschwindigkeit, wenn die Sperre sofort erreicht werden kann? ⇐ C++

[Anonymous]

Ich verwende eine plattformübergreifende API, die pthread_mutex_t für bereichsbezogene Sperren verwendet, um sicherzustellen, dass Dinge nicht das tun, was sie nicht tun sollten. Ich möchte nach Möglichkeit die von dieser API bereitgestellten bereichsbezogenen Sperrmethoden verwenden, um die Konsistenz zu gewährleisten.
Was genau passiert, wenn pthread_mutex_t die Sperre sofort erreicht? Ist es ein superschneller Prozess (nur wenige CPU-Zyklen) oder muss das System eine langsame Betriebssystemmethode aufrufen, bevor die Ausführung fortgesetzt werden kann?
Ich baue ein Echtzeitsystem auf, das so schnell wie möglich sein muss, da es Echtzeit-Audio verarbeitet und nach Möglichkeit nicht hängen bleiben sollte. Diese Mutexe werden unzählige Male pro Sekunde überprüft. Deshalb frage ich. Meine andere Alternative wäre die Verwendung von std::atomic_flag:

Code: Select all

        while (m_atomic_flag.test_and_set());

Das wäre für meinen Zweck sehr schnell, hat aber den Nachteil, dass der gesamte CPU-Kern blockiert, wenn die Sperre nicht erreicht wird. Wenn pthread_mutex_t also wirklich schnell wäre, wenn es die Sperre tatsächlich SOFORT erhalten KANN, wäre das für meine Verwendung optimal.
Was ich in meinem Fall also wirklich brauche, ist, dass die Sperre sofort innerhalb weniger CPU-Zyklen erfolgt, wenn sie verfügbar ist. Wenn der Prozess auf die Sperre warten muss, kann dies so lange dauern, wie der Prozess benötigt. Daher muss die Weiterleitung so schnell wie möglich erfolgen.
Kann ich pthread_mutex_t sicher verwenden, oder sollte ich einfach std::atomic_flag verwenden?
Ich habe versucht, durchzulesen. Für kritische Abschnitte – wann sollte man std::mutex vs. std::atomic_flag verwenden? aber das deckt nicht wirklich meinen Echtzeitfall ab.