[dataflow]

I'm not sure which issue you're referring to, but the one I was trying to address was the one above about the spinning itself causing a priority inversion: "you now have a descheduled thread that owns the lock and a spinning thread waiting to acquire it, which is a recipe for priority inversion."

[monocasa]

A) it's not just a priority inversion. The problem happens with simple round robin schedulers too.

B) The problem is the descheduled thread which has the lock and isn't in the lock sequence. Simply killing the time slice of the spinning thread without knowing what it's waiting on may lead to even worse behavior.

The answer here is simple: just don't use pure spinlocks if you can be preempted.

[dataflow]

> 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.

[munch117]

Your idea doesn't solve the problem. By the time the lock acquirer is pre-empted and the kernel has a chance to do something clever, a significant fraction of a timeslice has already been wasted.