Re: [PATCH v6 4/5] MCS Lock: Barrier corrections

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Fri, Nov 22, 2013 at 12:09:31PM -0800, Linus Torvalds wrote:
> On Fri, Nov 22, 2013 at 12:06 PM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
> >
> > I am sorry, but that is not always correct.  For example, in the contended
> > case for Tim Chen's MCS queued locks, the x86 acquisition-side handoff
> > code does -not- contain any stores or memory-barrier instructions.
> 
> So? In order to get *into* that contention code, you will have to go
> through the fast-case code. Which will contain a locked instruction.

So you must also maintain ordering against the critical section that just
ended on some other CPU.  And that just-ended critical section might
well have started -after- you passed through your own fast-case code.
In that case, the barriers in your fast-case code cannot possibly
help you.  Instead, ordering must be supplied by the code in the two
handoff code sequences.  And in the case of the most recent version of
Tim Chen's MCS lock on x86, the two handoff code sequences (release
and corresponding acquire) contain neither atomic instructions nor
memory-barrier instructions.

The weird thing is that it looks like those two handoff code sequences
nevertheless provide the unlock+lock guarantee on x86.  But I need to
look at it some more, and eventually run it by experts from Intel and
AMD.

							Thanx, Paul

> So I repeat: a "lock" sequence will always be a memory barrier on x86.
> 
>                    Linus
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>