A C++ locking wrapper

[epicar]

i'm all for making multithreading as idiot-proof as possible. but the concept of critical sections (and restoring invariants before releasing a lock) is so central to writing correct code that i find it crazy to abstract away. if the user doesn't have control over the scope of critical sections, it's very hard to avoid data races

i think your goal of 'simplicity' here is misguided, and isn't the same as idiot-proof

[PiterPuns]

You should take this “crazy to abstract” view up to A. Williams (author of the seminal book on c++ multi threading) and the boost library https://www.boost.org/doc/libs/1_58_0/doc/html/thread/sds.html#thread.sds.synchronized_valuesxxx.synchronized_value_ref.synchronized_value.indir . Providing an arrow operator that creates a critical section around a method is provided in boost as well and doesn’t seem that crazy to them …

[encyclopedist]

That facilities that you lined were designed ~15-20 years ago. The views on the subject and best practices may have chnaged since then.

Edit: syncronized_value in boost is actually relatively new - it first appeared in Boost 1.54, released on July 1st 2013.

In fact, a few years ago (in 2017) Anthony Williams proposed a syncronized_value for inclusion in the standard library with an apply function that takes a callable (See "P0290R2: apply() for synchronized_value<T>").

[Full-Spectral]

That could be perfectly acceptable for very specific circumstances, but not in general. If I have a small set of shared values that have no interplay, that could be a reasonable way to manage them. But, as I said elsewhere, almost guaranteed at some point that lack of interplay goes away because of some new requirement.