GP isn't totally wrong. With folly::Synchronized, you can lock, take a reference, then unlock, and continue to (incorrectly/unsafely) use the reference. The compiler doesn't catch that.
folly::Synchronized<int> lockedObj;
auto lockHandle = lockedObj.wlock();
auto& myReference = *lockHandle;
lockHandle.unlock();
myReference = 5; // bad
Still, it is harder to misuse than bare locks unattached to data.
Yes, but you can also take a reference (copy a pointer), delete, and continue to use the reference etc. I was pointing out that this is simply a lifetime/ownership issue, not an issue specific to locking (and yes, Rust solves that issue, at least for the easy cases). And as far as the problem is protecting access to a locked resource, a class like folly::Synchronized does indeed solve the problem.
