search

bepzi / elysium

A JUCE app with Rust guts
GNU General Public License v3.0
4 stars 0 forks source link

Investigate whether std::mutex::try_lock() is realtime-safe #15

Open bepzi opened 2 years ago

bepzi commented 2 years ago

My clever trick with try_lock() might not be realtime safe, even if we intend not to acquire the lock, since it might interact with the OS thread scheduler regardless: https://www.youtube.com/watch?v=Tof5pRedskI&t=2280s

Although in the Q&A sessions, the speaker does imply that if everyone is doing try_lock() and never lock(), it might be okay?

Originally posted by @bepzi in https://github.com/bepzi/elysium/issues/10#issuecomment-1009514407

bepzi commented 2 years ago

Regardless of the answer, I'd like to make sure the try_lock() code isn't compiled for release builds.

bepzi commented 2 years ago

Alternatively, careful use of std::atomic<bool> might be enough to track whether the Rust AudioProcessor is currently "in use" by another thread. Then we don't need an entire mutex, and I can be confident that what we're doing is realtime safe.