MCS locks and qspinlocks

Posted Mar 12, 2014 23:04 UTC (Wed) by james (guest, #1325)
In reply to: MCS locks and qspinlocks by rriggs
Parent article: MCS locks and qspinlocks

If I'm reading this correctly (and it's quite possible I'm not), the scenario would be something like:

CPU1 obtains a lock;
CPU2 tries to get the same lock, fails, and becomes next in line;
CPU3 tries to get the same lock, fails, and becomes second in line;
CPU2 is pre-empted by an interrupt;
CPU1 releases the lock;

Then CPU3 is still waiting for CPU2 to release the lock, which it won't do until it has returned from its interrupt handling and done whatever needed to be protected by the lock. With conventional spinlocks, CPU3 would have obtained the lock and could be doing something productive while CPU2 was still handling the interrupt.

What I'm not sure about is how often this situation will arise in practice. Obviously, you have to have a lock with at least two CPUs waiting for the situation to arise, and an interrupt being handled on the wrong CPU at just the wrong time. It looks like this is sufficiently infrequent that the performance hit when this happens is dwarfed by the performance benefits of the technique, but it would probably be a good idea to retry the benchmark on a machine subject to a network storm.

to post comments

MCS locks and qspinlocks

Posted Mar 13, 2014 3:15 UTC (Thu) by martinfick (subscriber, #4455) [Link] (1 responses)

> It looks like this is sufficiently infrequent

I wonder about that since these locks are meant for highly contentious locks!

MCS locks and qspinlocks

Posted Mar 13, 2014 14:30 UTC (Thu) by raven667 (subscriber, #5198) [Link]

And a corollary that on a computer, a one in a million chance race is going to happen all the time, frequent and infrequent have different meanings than colloquial use.

MCS locks and qspinlocks

Posted Mar 13, 2014 11:23 UTC (Thu) by dvrabel (subscriber, #9500) [Link]

I think ticket locks have the same behavior as you describe.

MCS locks and qspinlocks

Posted Mar 13, 2014 15:55 UTC (Thu) by andresfreund (subscriber, #69562) [Link] (1 responses)

> CPU1 obtains a lock;
> CPU2 tries to get the same lock, fails, and becomes next in line;
> CPU3 tries to get the same lock, fails, and becomes second in line;
> CPU2 is pre-empted by an interrupt;
> CPU1 releases the lock;

Preemtion is disabled appropriately during spinlock acquiration IIRC.

MCS locks and qspinlocks

Posted Aug 23, 2024 12:53 UTC (Fri) by 301043030 (guest, #172920) [Link]

only process preemption is disabled, interruption is also valid.