> it's not just a priority inversion.
Did I claim it was...?
> Simply killing the time slice of the spinning thread without knowing what it's waiting on may lead to even worse behavior.
It's not obvious to me how likely this is compared to the other case, but if you're trying to make a case for why a kernel doing that would result in worse behavior in typical cases, it would probably help to explain this.
> The answer here is simple: just don't use pure spinlocks if you can be preempted.
I don't get why you're arguing with me on this. I wasn't telling anyone to use spinlocks, nor claiming this is the one and only problem with spinlocks. I was just saying a kernel could be a little smarter about a particular case by examining the instruction sequence.