Implement the os_unfair_lock functions on macOS#3745
Conversation
| libc::os_unfair_lock_assert_not_owner(lock.get()); | ||
| } | ||
|
|
||
| // `os_unfair_lock`s can be moved and leaked: |
There was a problem hiding this comment.
What if they get moved while being locked?
There was a problem hiding this comment.
Nothing, the lock continues to function. We can in all likelihood rely on this, because the lock is unlocked in userspace before entering the kernel, which means the kernel cannot rely on the lock being present when doing the wake, as another thread might lock, unlock and deallocate it immediately. And as the userspace code cannot rely on the lock being fixed either – the structure is too small to contain a pointer – we can do all the moving and leaking we like.
|
Looks good, thanks a lot! I also filed #3749 to track adjusting our shared lock implementations so that they can be address-sensitive the way they should be. Please squash the commits. |
I could change this to use the futex API like the real implementation, which would make this behave exactly the same way. |
|
@bors r+
That seems a bit awkward to implement inside Miri... also, we'd want to raise UB when doing things that are not guaranteed by the implementation, so having exactly the same implementation does not seem quite right. |
|
☀️ Test successful - checks-actions |
3 participants
These are needed for rust-lang/rust#122408. See the documentation here and the implementation here.