Is it safe to use std::mutex::try_lock or ScopedTryLock on the realtime thread?

[nicolasdanet]

(Sorry it is a 3 years old thread, but i have exactly the same question.)

In the Timur Doumler’s blog it is said that it is NOT safe due to mutex_unlock. But i read a paper about that approach few time ago that doesn’t refer to this problem (sorry in french) < https://hal.archives-ouvertes.fr/hal-01791422/document >.

I would like to get POV about that:

1. Is it a theoretical case, or did people really experienced such blocking while unlocking the mutex?
2. When replacing the mutex by a spin lock, what’s happen if the DSP thread is preempted with the lock aquired (especially with ONE core)?

Real-Time Multi-Threading in an Audio Application

Hi, I have read many topics on here about using multi-threading for dsp and other real-time audio purposes in audio plugins. The majority of people seem to say not to do it due to the host application already performing thread management and optimisation. I am curious about this topic when it comes to general audio applications. Obviously multi-threading in real-time comes with its own difficulties such as thread synchronisation and avoiding allocations/os calls. However is there a general cons…