The Oboe documentation says that some functions are thread-unsafe and are recommended to be protected with a mutex. https://github.com/google/oboe/blob/master/docs/FullGuide.md#thread-safety.
getTimestamp is a getter. Can you clarify what exactly is thread-unsafe about it? Is it simply not guaranteed to be monotonically increasing between threads? Is there an actual race condition between what sets some underlying state and that state as it is read by AAudio? is getTimestamp modifying state of the underlying stream in some way that is unsafe?
I wasn't able to find the implementation of getTimestamp. It seems AAudio asks the audio stream https://android.googlesource.com/platform/frameworks/av/+/master/media/libaaudio/src/core/AAudioAudio.cpp#519. But the audio stream asks AAudio? https://android.googlesource.com/platform/frameworks/av/+/master/media/libaaudio/src/core/AudioStream.h#99
--
EDIT: Can you clarify how to be thread safe? I understand the desire to lock on a mutex for shared memory, but that is only an option (1) if you can tolerate locking, and (2) have access to a shared mutex. Is there a shared mutex or a memory fence that protects the memory? Typically for audio applications we cannot tolerate locking inside an audio callback, so are there lock-free solutions?
This article suggests that the data may be written in a register that is not safe to read on another CPU https://linux.die.net/man/3/clock_gettime. Is getTimestamp using this implementation? Can you clarify who writes to whatever memory holds the timestamp? Is there any way to ensure that the caller is calling on the same CPU and it is providing real values for the timestamp?