RE: spin_unlock optimization(i386)

David Schwartz (
Fri, 26 Nov 1999 17:05:45 -0800

> as far as i understand it (reading only this thread, no Intel docs),
> under Processor Order, CPU B sees stores made by CPU A in order, but
> possibly delayed. I was wondering if this may cause unnecessary spins
> on a CPU which is spinlocking, "waiting" to acquire the lock: it is
> possible that CPU A releases the lock with a store, and CPU B doesn't
> see it for a while? Note that this is not an ordering issue:

Absolutely. But the consensus seems to be that there's no good way to
minimize this delay that doesn't cost more than it gains.

> So, my question: can reads made by CPU B on the lock variable see an old
> value (=busy) even after the unlock() made by A, for a while? And if yes,
> how big is this interval (after all, B is really wasting cycles...)?

Yes, for a while. How large the interval is depends primarily on how long
write-back can take.

> If not, does it mean that the serializing lock read made by CPU B
> while spinlocking force a global (=on all CPUs) commit of any pending
> store (thus making all the system work as WT for all the time B
> spinlocks)?

Memory barriers enforce order. They can't force an actual commit.

> So, either 1) we're wasting cycles on CPU B spinning on a *free* lock (for
> a while), or 2) the whole system performs as WT (or even worst) while B
> is spinning. Am i missing something?

You are correct. The same applies (generally) to user-level mutexes.
Usually, a mutex lock is implemented as:


And an unlock as:


While this ensures correct behavior, it does not assure that you don't wait
'too long'. And a memory barrier can't do that anyway.

The cache coherency logic, on the other hand, should assure that the loop
eventually reads the right data, since it forces the cache of that processor
to assume ownership (or at least shared ownership) of that chunk of memory.

> 1) could be solved forcing a commit on CPU A right after (as part of) s
> the unlock() (but, is it possible? were we doing precisely that, before
> the whole thread starts?);

What does 'forcing a commit' mean? You're not suggesting the cache be
flushed, are you?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at