5 ms·
Rust solves this (in common cases) by having the mutex wrap the data it protects. You can't make this mistake because you can't perform any operation without fi
by Thiez 3y ago
Rust solves this (in common cases) by having the mutex wrap the data it protects. You can't make this mistake because you can't perform any operation without first taking the lock.
Of course this doesn't cover all usecases but hopefully the people who have the exceptional situation are smart enough to avoid the problem in the article.
- chadaustin 3y agoYou can still put atomics outside the mutex in Rust.
- kentonv 3y agoFWIW, my C++ toolkit library, KJ, does the same thing.[0] But presumably you could still write a condition predicate which looks at things which aren't actually part of the mutex-wrapped structure? Or does is the Rust type system able to enforce that the callback can only consider the mutex-wrapped value and values that are constant over the lifetime of the wait? (You need the latter e.g. if you are waiting for the mutex-wrapped value to compare equal to some local variable...) [0] https://github.com/capnproto/capnproto/blob/e6ad6f919aeb381b40d535b58dad96d97103333c/c++/src/kj/mutex.h#L415 https://github.com/capnproto/capnproto/blob/e6ad6f919aeb381b...
- plorkyeran 3y agoRust does not solve this by having the mutex wrap the data it protects. The problem is checking something in the condition variable's predicate which isn't guarded by the mutex. Stopping you from accessing the data guarded by the mutex without holding the mutex does nothing to help with this. You would need to make it so that the CV predicate can only access the state guarded by the mutex, which is not something that Rust does.