4 ms·
Or you could give `MutexLocker` pointer semantics to access the underlying object only through the lock, which would probably be more idiomatic c++ anyways.
by chombier 4y ago
Or you could give `MutexLocker` pointer semantics to access the underlying object only through the lock, which would probably be more idiomatic c++ anyways.
- Yoric 4y agoLifetimes might be a bit trickier, though.
- chombier 4y agoIndeed, with lambdas you don't need to deal with locks outliving the underlying object (though I think std::unique_lock has the same issue with the underlying mutex?) The downside with lambdas is that you cannot lock across function boundaries e.g. give ownership of a lock to the caller. There's a similar tradeoff for all "context managers" (in Python parlance) where you could either CPS your way around the control flow (the lambda approach) or use c++'s RAII mechanism. My impression is that RAII feels a bit more idiomatic and puts the burden on library writers instead of users.
- saagarjha 4y agoIndividual accesses are typically the wrong level of abstraction for synchronization. You’ll avoid simple data races but it’s easy to have accidental reentrancy this way.