lkml.org 
[lkml]   [2009]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH -v5][RFC]: mutex: implement adaptive spinning


On Wed, 7 Jan 2009, Linus Torvalds wrote:
>
> We don't actually care that it only happens once: this all has _known_
> races, and the "cpu_relax()" is a barrier.

I phrased that badly. It's not that it has "known races", it's really that
the whole code sequence is very much written and intended to be
optimistic.

So whatever code motion or whatever CPU memory ordering motion that
happens, we don't really care, because none of the tests are final. We do
need to make sure that the compiler doesn't optimize the loads out of the
loops _entirely_, but the "cpu_relax()" things that we need for other
reasons guarantee that part.

One related issue: since we avoid the spinlock, we now suddenly end up
relying on the "atomic_cmpxchg()" having lock acquire memory ordering
semantics. Because _that_ is the one non-speculative thing we do end up
doing in the whole loop.

But atomic_cmpxchg() is currently defined to be a full memory barrier, so
we should be ok. The only issue might be that it's _too_ much of a memory
barrier for some architectures, but this is not the pure fastpath, so I
think we're all good.

Linus


\
 
 \ /
  Last update: 2009-01-07 23:09    [W:0.213 / U:1.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site