[ was off traveling, sorry for late answer ]

Paul A. Clayton (paaronclayton.delete@this.gmail.com) on August 28, 2012 10:28 am wrote:
>
> How can a compiler recognize a locked critical
> section and not be able to recognize at least most of the possible uses of
> ll/sc? Recognizing a sequence that only loads one value from memory, performs
> some computation, then replaces the value with a new value (and that being the
> only store operation and--at least for most ISAs--the only memory operations
> allowed are the ll/sc [IIRC, Alpha also failed sc on a taken branch.])
>
> ll/sc
> is such a limited form of transactional memory that recognizing most possible
> uses would seem not to be too difficult.

Umm. It's not just the "load-op-store" sequence under a lock.

It's the lock itself!

Doing a spinlock around a load-op-store sequence is *not* something that is equivalent to doing the load-op-store as a ll/sc sequence. Yes, both are "atomic". No, they are not the same thing at all despite that.

In particular, another much longer sequence somewhere else may run under the spinlock, and depend on the fact that nothing that lock changes is changing - over long periods. It may do multiple loads of the value, and the lock guarantees that the value has to stay the same.

So no, a compiler can absolutely not change a locked atomic load-op-store sequence into a ll/sc sequence. The two have absolutely zero in common - they are both "atomic", but they are atomic in totally different ways.

So ll/sc is pretty much useless as anything else than a replacement for the CISC kind of "atomic increment/cmpxchg/whatever" instruction. It has absolutely nothing to do with transactional memory that can elide locks.

Don't confuse the two. They really have nothing in common, and "atomic" really means many different things.

Having a compiler recognize a lock, and turning it into a lock-elision sequence (that has the *semantics* of a lock) is trivial. In fact, the compiler doesn't even need to do it, you can just do the lock-eliding part as a function call or inline asm. Exactly because unlike ll/sc, it actually has the right semantics.

Linus