Paul A. Clayton (paaronclayton.delete@this.gmail.com) on August 22, 2012 10:20 am wrote:
>
> Many critical sections are small--intentionally so because a long
> critical section is likely to reduce parallelism. Without additional (complex)
> hardware to order transactions so that they do not conflict, most large
> transactions might be likely to fail.

Many critical sections are really small, because they may be implementing things like atomic hash chain updates etc. So the lock may be protecting literally just a small handful of instructions - yet the sequence is not just about one or two words, so ll/sc wouldn't work.

That's where people who try to do scaling at any cost will have per-hashchain locks etc, but that eats memory and can cause other complexity problems (locking when moving things between hashchains atomically etc). So many normal programmers will rely on some generic hash library that probably has just a single lock for all the accesses.

That's a wonderful use-case for hardware lock elision. Keep the lock cacheline shared across CPU's, no need for the complexities of multiple locks, things "just work". And I think it's a fairly common case.

More importantly, even if ll/sc could work in some particular case, realistically people wouldn't actually use ll/sc, because it's basically impossible to do portably, and it's not generally amenable to the compiler doing it automatically. In contrast, lock elision with small transactions is amenable to doing automatically from portable source code.

Note: "portable" here doesn't necessarily mean "works across many architectures". It can mean "works together with code that is written to work for a previous generation of the CPU that didn't have the transactional capability". So when I say "portable", I don't mean the Linux kind of "portable to the 30 different architectures we support", I mean the Windows or OSX kind of "we can use the same codebase without major pain for different versions of Intel chips".

Linus