I'm using a multi-platform API which uses pthread_mutex_t for scoped locks, to ensure things don't do what they shouldn't be doing. I want to use the scoped lock methods provided by this API, if possible to keep things consistent.

What exactly happens when pthread_mutex_t DOES achieve the lock straight away? Is it a super fast process (only few CPU cycles) or does the system have to call some slow OS method before the execution can continue?

I'm building a realtime system which needs to be as fast as possible since it's processing realtime audio and shouldn't get hung up whenever possible. Those mutexes will be checked tons of times a second. That's why I'm asking. My other alternative would be to use std::atomic_flag:

        while (m_atomic_flag.test_and_set());

That would be really fast for my purpose, but it has the downside of stalling the whole CPU core if the lock is not achieved. So if the pthread_mutex_t would be really fast when it actually CAN get the lock IMMEDIATELY, that would be optimal for my use.

So in my case what I really need is that the lock happens immediately inside few CPU cycles when its available. If the process needs to wait for the lock to happen, then it can take as much time as the process needs. So the pass-through must be as fast as possible.

Am I safe to use pthread_mutex_t or should I just use std::atomic_flag?

I tried reading through For critical sections - when to use std::mutex vs std::atomic_flag? but that does not really cover my realtime case.