Aaron Spink (aaronspink.delete@this.notearthlink.net) on August 16, 2014 10:25 pm wrote:
> Maynard Handley (name99.delete@this.name99.org) on August 16, 2014 2:24 pm wrote:
> > Likewise for synchronization primitives. The consensus as I read the literature is
> > that load locked/store conditional is substantially easier to implement and get right
> > than LOCK prefixes and the random mix of other things that Intel has. I'm guessing
> > it's then also easier to build HW TM on top of load locked/store conditional.
> > Beyond this, I'm guessing it's substantially harder to design for and verify
> > the Intel memory model than the looser POWER and ARM memory models.
> >
> Actually, many software people have come to mostly loathe LL/SC and its been
> involved an lots of bugs of either software or hardware over the years. The
> truth is that LL/SC is pretty much only used for effectively CMPXHG.
>
> And its generally easier to design and verify for the x86 MOM than for any of the more relaxed
> memory models. Esp from a software perspective. And from a performance perspective, because of
> the software issues, the stricter MOMs tend to have better performance. AKA with a weaker MOM,
> software developers tend to be much more cautious which leads to lower performance. So far, the
> performance/strictness relationship with MOMs has been a case of Theory != Practice.
>
> Maynard, you've been around long enough that you've almost certainly seen Linus
> rant #X on this topic. This is definitely one of those areas where I agree with
> Linus. Make it easier for the programmers, hardware designers be dammed.

Does it matter much that the only thing LL/SC is used for is CMPXHG? I always thought that WAS pretty much the entire point --- it gives the HW an easier way to implement CMPXHG, and if you want to go off and do anything extra with them, go right ahead, but the HW was not designed with those extra capabilities in mind.

Linus is welcome to his rants; I've ranted plenty in my time. But I think we have to distinguish between
- this is optimal for ME AND MY TEAM because we've created a particular OS model which is centered around x86 capabilities and
- this is optimal for ANYONE working at the OS level and
- this is optimal for the HW (and let's face it, OS developers and compiler writers are a very small fraction of developers, let alone users, so if doing things this way helps everyone else it's a win)

Certainly I was not convinced, after we went through the last version of "inverted page tables suck" that the CONCEPT was intrinsically bad. I read a lot of material about it from various sources, and the pattern I saw was that the Linux guys had (for defensible reasons) a very specific idea in mind of how they wanted to implement page tables, and their complaints seemed more to come down to "we can't efficiently implement the x86 design pattern on this HW" than anything deeper than that.

So getting back to LL/SC, was it considered in, say, the context of Alpha and Ultrix a terrible idea? Would the alternatives have been better?