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:
lock();
mb();
And an unlock as:
mb();
unlock();
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?
DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/