Yep, it's a useful pattern albeit not a game changer or anything. I've been using it in Kotlin for a while. Here's an implementation: https://gist.github.com/m

Yep, it's a useful pattern albeit not a game changer or anything. I've been using it in Kotlin for a while. Here's an implementation: https://gist.github.com/mikehearn/1913202829403f65331123f0473a7901 https://gist.github.com/mikehearn/1913202829403f65331123f047... One of the nice things about doing it in Kotlin rather than C++ is the clean syntax using trailing lambda blocks and anonymous objects: private val state = Locker(object { var value = 1 var another = "value" }) val nextValue = state.locked { ++value } This works because Kotlin lets you define anonymous types that can take part in type inference even though they're not denotable, and then use them as lambda receivers. So "this" inside the final block points to the unnamed singleton. It has a few nice features: • It's runtime overhead free. Kotlin frontend can inline the "locked" call so you end up with the equivalent of manual locking. • There's no way to get to the state without holding the lock unless you deliberately leak it outside the lambda. • You can control re-entrancy. • It tells the compiler the lambda is only invoked once, which has various benefits for allowing more natural code constructs. These days I'd probably code it with an explicit ReadWriteLock so it's Loom compatible and to allow explicit read/write blocks, but the JVM optimizes locks pretty well so if there's never any contention the memory for the lock is never allocated. I'd also experiment with making it value type so the overhead of the Locker object goes away. But it was never necessary so far.