MCS locks and qspinlocks

Posted Mar 12, 2014 1:32 UTC (Wed) by ncm (guest, #165)
Parent article: MCS locks and qspinlocks

According to the description, mcs_lock_t::locked seems to always be only 1 or 0, but it is described as a counter. It seems, too, that locked is only ever updated by the holder of the lock. Could it not be stolen from mcs_lock_t::next, resulting in fewer memory bus operations and a one-word pointer?

Furthermore... why use MCS at all if qspinlocks are both smaller and faster? Should all the MCS locks become qspinlocks, over time?

to post comments

MCS locks and qspinlocks

Posted Mar 12, 2014 11:40 UTC (Wed) by corbet (editor, #1) [Link] (2 responses)

The qspinlock implementation actually uses MCS locks - but only the four-element per-CPU array of them. So the MCS locks won't go away. That array would also be insufficient if one were to try to put qspinlocks into mutexes, since those can sleep and an arbitrary number of them can be acquired.

MCS locks and qspinlocks

Posted Mar 21, 2014 0:29 UTC (Fri) by kevinm (guest, #69913) [Link] (1 responses)

Mutexes can't sleep while holding a spinlock, though.

MCS locks and qspinlocks

Posted Mar 25, 2014 1:47 UTC (Tue) by joern (guest, #22392) [Link]

The array is not for processes holding a lock, but for processes sleeping on a lock. If it were for processes holding a lock, it wouldn't even be sufficient for regular spinlocks.

MCS locks and qspinlocks

Posted Mar 20, 2014 15:21 UTC (Thu) by icefield (guest, #82338) [Link]

Yeah that's a good point, who can please answer the question why we can't override mcs_lock_t::next for mcs_lock_t::locked?