Out of Date
Neat idea, but this kind of concurrency problem has been sidestepped altogether decades ago. Concurrent formulations such as Actor Model and, more importantly, Communicating Sequential Processes are 1970s ideas. The latter in particular is highly relevant to anyone wanting code that executes concurrently which is provably free of deadlock, livelock and spinlock problems as well as having zero memory sharing errors. There's even a process calculus for it.
CSP was briefly fashionable back in the 1980s, early 1990s (Inmos's Transputers, Occam), but is now alive and well in languages such as Erlang, Rust, Go, Scala. Of those, Rust in particular looks really good (no runtime needed, ideal for all sorts of software and not just desktop applications like web browsers). I'm perverse, choosing to do CSP architectures in C/C++ (I have to have a library...).
This is clearly the way to go for future developments. Sticking with the old "lets share memory and guard it with a semaphore" is not faster to run, is a lot longer to debug (even with tools like this from Facebook), and is prone to stinging you in the arse years down the line when some unexpected sharing issue finally occurs for the first time.
It is also inherently limiting when one wants to scale up a piece of software across a whole network of computers; Actor Model or CSP channels can be network connections; shared memory / semaphores cannot. Shared memory architectures fundamentally require an SMP computer; that's increasingly becoming a bottleneck in future CPU speed improvements; massive chunks of modern Intel CPUs, and especially AMD CPUs, are dedicated to synthesising an SMP environment from an underlying NUMA architecture.
Whereas CSP / Actor Model architectures are entirely happy with NUMA. A computer that is a pure NUMA machine would be a lot more power efficient (or faster, depending on how you want to adapt).