On Thu, Dec 19, 2013 at 6:22 PM, Davidlohr Bueso <davidl...@hp.com> wrote: > > Ok so when I replied I was thinking about the plist really and not the > hb->lock ticket counter. Yeah, what you propose does make sense for > waiters. However in wake paths we have to decrement the counter nwake > times (per each call to __unqueue_futex()), and if we rely on the > ticket, then we do it only once, in the unlock, so the counter doesn't > reflect the actual waitqueue size. Or am I missing something with ticket > spinlocks (I'm not very familiar with that code)?
So that's why I suggested checking the ticket lock _and_ the state of the node list. The ticket lock state gives you the racy window before the entry has actually been added to the node list, and then after the lock has been released, the fact that the list isn't empty gives you the rest. I think we might have to order the two reads with an smp_rmb - making sure that we check the lock state first - but I think it should be otherwise pretty solid. And maybe there is some reason it doesn't work, but I'd really like to understand it (and I'd like to avoid the extra atomics for the waiters count if it at all can be avoided) > Btw, I tried using spin_is_contended + plist_head_empty and we run into > a whole bunch of nasty issues which I have yet to sit down and look > into. Yeah, I said "spin_contended()" myself initially, but it needs to be "spin_is_locked()". It's hopefully unlikely to ever actually be contended (which in ticket lock terms is "head is _more_ than one away from the tail"). Linus -- 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/