tgoyne
commented
2 years ago We do wait on a mutex where possible. There's two scenarios where we don't:
- InterprocessMutex, as the name suggests, implements a mutex which is shared between all processes which open a given Realm file. Apple's implementation of process-shared mutexes doesn't actually work (FB5978435), so we have to emulate it with IPC mechanisms that do work.
- Async writes let you acquire the write lock asynchronously and be notified when it's acquired, which is inherently a pattern which can't be implemented via a mutex and is where we use semaphores instead. Here we probably need to be using manual QoS overrides.
hamzasohail
jedelbo
There was a report from a user who observed a "Hang Risk" runtime issue in Xcode when running their app when using the Realm SDK.
https://www.mongodb.com/community/forums/t/hang-risk-thread-warning-on-xcode/177869
There is explicit guidance by Apple about the risk associated with this primitive. Upon examination, it seems realm implements mutexes (realm-core/src/realm/util/interpocess_mutex.cpp) with dispatch semaphores. This is risky -- dispatch semaphores do not provide priority inversion avoidance since the system doesn't know which thread will eventually signal the waiting thread.
Instead, I propose that for mutexes (and other locking primitives you provide), you should use OS unfair locks instead which provide priority inversion avoidance (this explicit guidance is available in this talk: https://developer.apple.com/videos/play/wwdc2017/706/)