On Wed, May 02, 2018 at 03:53:47AM +0000, Daniel Colascione wrote: > The usual approach to "better" is an "adaptive mutex". Such a thing, when > it attempts to acquire a lock another thread owns, spins for some number of > iterations, then falls back to futex. I guess that's a little better than > immediately jumping to futex, but it's not optimal. We can still spin when > the lock owner isn't scheduled, and the spin count is usually some guess > (either specified manually or estimated statistically) that's not > guaranteed to produce decent results. Even if we do pick a good spin count, > we run a very good chance of under- or over-spinning on any given > lock-acquire. We always want to sleep when spinning would be pointless. Look for the FUTEX_LOCK patches from Waiman. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
