[socmag]

In my personal experiences I've seen quite the opposite.

Specifically, this kind of starvation mostly occurs only in synthetic lock benchmarks.

In the real world, cores should be actually doing work in between spinning on cache-line locks; and the time before they get back to locking should be fairly random by quite a reasonable number of cycles - which tends to largely mitigate the starvation issue you talk about.

Basically, if you have code that is structured to by default sit on spin-locks, there is likely an architectural issue in play.

I'd go with the other contributor who said something along the lines of "the best policy is to go with the fastest lock possible", unless there is some very niche reason not to.