Compiler use of ll/sc?

Article: Haswell Transactional Memory Alternatives
By: Linus Torvalds (torvalds.delete@this.linux-foundation.org), September 8, 2012 1:58 pm
Room: Moderated Discussions
[ 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
< Previous Post in ThreadNext Post in Thread >
TopicPosted ByDate
Article: Haswell TM AlternativesDavid Kanter08/21/12 10:17 PM
  Article: Haswell TM AlternativesHåkan Winbom08/22/12 12:52 AM
    Article: Haswell TM AlternativesDavid Kanter08/22/12 02:06 AM
  Article: Haswell TM Alternativesanon08/22/12 09:46 AM
    Article: Haswell TM AlternativesLinus Torvalds08/22/12 10:16 AM
      Article: Haswell TM AlternativesDoug S08/24/12 09:34 AM
    AMD's ASF even more limitedPaul A. Clayton08/22/12 10:20 AM
      AMD's ASF even more limitedLinus Torvalds08/22/12 10:41 AM
        Compiler use of ll/sc?Paul A. Clayton08/28/12 10:28 AM
          Compiler use of ll/sc?Linus Torvalds09/08/12 01:58 PM
            Lock recognition?Paul A. Clayton09/10/12 02:17 PM
              Sorry, I was confusedPaul A. Clayton09/13/12 11:56 AM
  Filter to detect store conflictsPaul A. Clayton08/22/12 10:19 AM
  Article: Haswell TM Alternativesbakaneko08/22/12 03:02 PM
    Article: Haswell TM AlternativesDavid Kanter08/22/12 03:45 PM
      Article: Haswell TM Alternativesbakaneko08/22/12 10:56 PM
  Cache line granularity?Paul A. Clayton08/28/12 10:28 AM
    Cache line granularity?David Kanter08/31/12 09:13 AM
      A looser definition might have advantagesPaul A. Clayton09/01/12 07:29 AM
    Cache line granularity?rwessel08/31/12 08:54 PM
      Alpha load locked granularityPaul A. Clayton09/01/12 07:29 AM
        Alpha load locked granularityanon09/02/12 06:23 PM
          Alpha pages groupsPaul A. Clayton09/03/12 05:16 AM
  An alternative implementationMaynard Handley11/20/12 10:52 PM
    An alternative implementationbakaneko11/21/12 06:52 AM
      Guarding unread values?Paul A. Clayton11/21/12 09:39 AM
        Guarding unread values?bakaneko11/21/12 12:25 PM
    TM granularity and versioningPaul A. Clayton11/21/12 09:27 AM
      TM granularity and versioningMaynard Handley11/21/12 11:52 AM
        Indeed, TM (and coherence) has devilish details (NT)Paul A. Clayton11/21/12 11:56 AM
Reply to this Topic
Name:
Email:
Topic:
Body: No Text
How do you spell blue?