lkml.org 
[lkml]   [1999]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: spin_unlock optimization(i386)

On Thu, 25 Nov 1999, Linus Torvalds wrote:

> Everybody has convinced me that yes, the Intel ordering rules _are_
> strong enough that all of this really is legal, and that's what I
> wanted. I've gotten sane explanations for why serialization (as
> opposed to just the simple locked access) is required for the lock()
> side but not the unlock() side, and that lack of symmetry was what
> bothered me the most.
>
> Oliver made a strong case that the lack of symmetry can be adequately
> explained by just simply the lack of symmetry wrt speculation of reads vs
> writes. I feel comfortable again.

i believe the lack of symmetry is due to the unique assymetry of 'lock
aquire' operations vs. 'lock release'. lock-acquire has to be an atomic
test-and-set, and this can only be guaranteed via explicit MESI-helped
LOCK-prefix instructions. The 'lock release' operation on the other hand
can be executed without caring too much about the current state of the
lock, because we _know_ that we are holding the lock already. This unique
assymetry is true even in the Strongly Ordered memory model with no
speculative reads done at all.

> Thanks, guys, we'll be that much faster due to this..

definitely :) The code generated in the SMP kernel is starting to look
like the UP one, both assembly and performance-wise. Cool.

-- mingo


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.086 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site