Open fbq opened 2 years ago
Very cool find, @fbq !
I'm not a big fan of the idea of having extra atomic incs/decs on the lock/unlock paths as that would clearly make the Rust version more expensive. We may have to do it though if we can't find another way of dealing with this. Let me think about this for a bit.
Very cool find, @fbq !
I'm not a big fan of the idea of having extra atomic incs/decs on the lock/unlock paths as that would clearly make the Rust version more expensive. We may have to do it though if we can't find another way of dealing with this. Let me think about this for a bit.
I share the same worry about having extra atomic incs/decs. Maybe we just make lock_noguard
unsafe
, because most of the lock users will use Guard
-API, plus if a user use lock_noguard
, the unsafe
unlock
will also be used, in other words, still need to engage with some unsafety.
I think the Guard
API is also unsafe because one can mem::forget
the Guard
(or leak it in a reference cycle).
I think the
Guard
API is also unsafe because one canmem::forget
theGuard
(or leak it in a reference cycle).
Ah, you are right.
@wedsonaf This came to me when I'm investigating the safety of
schedule
.Linux's
mutex_lock()
sets->lock
to the current task once the lock is grabbed. If another thread tries to grab the lock, instead of sleeping immediately, it will check whether the lock owner is on cpu or not (mutex
is a sleepable lock) viatask_struct::on_cpu
. And if the task is running on some CPU, the owner may finish its work soon and release the lock, so the other thread will spin instead of sleep.Consider the following case
This means
Mutex::lock_noguard()
is unsafe, and the safety guarantee would be making sure that a thread releases the lock before exiting or https://github.com/Rust-for-Linux/linux/pull/863 is needed