> What's needed is a CPU instruction to fence a critical section and lock up two cache lines while you manipulate them from one CPU, with other CPUs locked out.

> What's needed is a CPU instruction to fence a critical section and lock up two cache lines while you manipulate them from one CPU, with other CPUs locked out. Transactions should have a hardware instruction cycle limit, so you can't lock up the other CPUs for very long. Then you could do swaps, sets, appends to lists, and such with straightforward code. This is a perfect description... of non-atomic code. There's nothing atomic about mutual exclusion of cacheline access over multiple CPU instructions. As a bonus, we know how to lock a mutex without limits on instruction cycles etc. - this prevents any weird code geneneration limitations on JITs and compilers, meaning you can write normal straightforward code. You are, of course, recommended to lock for as short a time as possible where it makes sense as you say - so you don't lock up the other CPUs for very long. With this in mind... what exactly is your requested change to the status quo? Is it for cheaper mutex (un)locking instructions in non-contested scenarios? Or is it for other cores hitting the same cacheline as your "atomic" operation to do something different than what they currently do? Currently, common approaches include: - wait for the other operation to complete (aka spinlock) - switch to another, more productive task (aka block / context switch) - speculatively execute code and then throw away the result if there was a conflict (e.g. STM - you can do such things with existing atomic operations, although hardware support for conflict detection might be nice) Or maybe it's to lock by cacheline instead of explicitly named mutexes? This is easy enough to do with current tech - have an array of, say, 256 mutexes - and then lock the mutex at index size_t(address)/64%256. Maybe choose a prime number of buckets to reduce collisions - not an option if such a mechanism was baked into the silicone. EDIT: Or maybe you just want some instructions to discourage the OS from preempting your thread while holding inner locks?