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
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core