On Thu, 2013-12-19 at 15:14 -0800, Linus Torvalds wrote: > > So I still think this can be done without that new counter field, or > any new atomics. > > hb_waiters_pending() could be something like > > spin_contended(hb->lock) || !list_empty(&hb->chain) > > which considering where you increment the new count should be > equivalent to your "!!hb->waiters". The smp_mb_after_atomic_inc()" on > the spinlock side would become smp_mb_after_spin_lock() instead.
So we'd need the barrier right after the ticket increment (ie: the xadd TICKET_LOCK_INC in x86), and cannot rely on the barrier after the lock is taken as we could miss waiters that are just spinning trying to take it. Is this implicitly guaranteed across all archs? Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
