Hacker News Reader

Comment by Thiez | Hacker News Reader

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.

View on HN

Rust 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.

You can still put atomics outside the mutex in Rust.

FWIW, 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/e6ad6f919aeb381b...

Reply on news.ycombinator.com