Philippe Gerum wrote:
> On Fri, 2007-03-23 at 14:47 +0100, Jan Kiszka wrote:
>> That idea sounds worthwhile for xnlocks as well, doesn't it?
> 
> Not sure, yet. Real starvation on xnlocks would require non-RT activity
> to be completely locked out on all CPUs in the first place for that to
> happen, which would be the sign of a serious design flaw. I see no way
> to solve such initial problem by adding some fairness to the lock
> dispatching policy in primary mode.

I wasn't primarily thinking about avoiding starvation (would indeed be
bad if a system suffers from such a risk) but about making spinlock
contention more predictable in case that successive (but bounded) lock
acquisitions may occur.

> 
> Still, thinking about this patch, since there is a price to pay for this
> approach due to serious cache-bouncing on high contention, using the
> waiter priority to manage the pending queue instead of a simple FIFO
> ticketing would be at least logically better, but likely even more
> costly.

Yeah, I thought about such approaches as well before. Don't have my
drafts on this at hand, but it was costly, specifically /wrt spinlock size.

Jan