@SchrodingerZhu

Thank you for the patch, however, I have a major concern regarding it.

I think we should prefer

os_sync_wait_on_address
__ulock_wait

in this case:

• wait on address API is typically more modern. rust's std library, for example, is using it.
• it allows us to align futex-based code across platforms.
• have futex directly allow us to use existing sync primitives, including both raw mutex and call_once.

This also avoid unaligned behavior across platforms:
For example, in your code, you still handle the realtime as it is. However, as per bionic libc's discussion, realtime is almost never the expected behavior of the mutex. Hence, even if the user use realtime, the underlying mutex will still convert it to monotonic time. If you use raw mutex, this practice is directly applied.

So, instead of specialize mutex, let's make raw mutex a common library for both linux and darwin, by providing all futex
definitions.

Also, using user space busy loop to implement timed lock is definitely not what we want.

There are existing API like the following if you use the futex approach:

os_sync_wait_on_address_with_timeout

Thank you for the detailed review. I agree with you here. I went with os_unfair_lock primarily for simplicity. I'll take your suggestions, and reimplement this with os_sync_wait.