mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jamie Lokier <lk@tantalophile.demon.co.uk>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Bernd Schmidt <bernds@redhat.com>,
	Andreas Franck <afranck@gmx.de>,
	David Howells <dhowells@cambridge.redhat.com>,
	andrewm@uow.edu.au, bcrl@redhat.com, alan@lxorguk.ukuu.org.uk,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2nd try: i386 rw_semaphores fix
Date: Thu, 12 Apr 2001 10:38:03 +0200	[thread overview]
Message-ID: <20010412103803.B25536@pcep-jamie.cern.ch> (raw)
In-Reply-To: <Pine.LNX.4.30.0104111606010.1106-100000@host140.cambridge.redhat.com> <Pine.LNX.4.31.0104111118000.17733-100000@penguin.transmeta.com>
In-Reply-To: <Pine.LNX.4.31.0104111118000.17733-100000@penguin.transmeta.com>; from torvalds@transmeta.com on Wed, Apr 11, 2001 at 11:27:28AM -0700

Linus Torvalds wrote:
> 
> 
> On Wed, 11 Apr 2001, Bernd Schmidt wrote:
> See? Do you see why a "memory" clobber is _not_ comparable to a "ax"
> clobber? And why that non-comparability makes a memory clobber equivalent
> to a read-modify-write cycle?

I had to think about this, so I'll explain it a different way in case it
is helpful.

An "ax" clobber says "the whole of eax is undefined after this".  In
contrast, a "memory" clobber says "we are writing unspecified values to
unspecified addresses, but the values are actually valid if you read
memory later".

All earlier writes to any part of _addressed_ memory (or the named
register) must be either discarded, or placed earlier in the instruction
stream.  For "memory" this is a "compiler write barrier".  Addressed
memory means everything except local variables whose addresses are not
taken.

Later reads from memory could be reading from a region that was written
by the "memory" clobbering instruction.  The compiler doesn't know, so
it must assume so.  Therefore later reads must be placed later in the
instruction stream.  This means that "memory" acts as a "compiler read
barrier".

> In short: I disagree 100%. A "memory" clobber -does- effectively tell the
> compiler that memory is read. If the compiler doesn't realize that, then
> it's a compiler bug waiting to happen. No ifs, buts of maybes.

Indeed.

-- Jamie

  reply	other threads:[~2001-04-12  8:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3AD45EC5.81EB82AD@akustik.rwth-aachen.de>
2001-04-11 14:17 ` David Howells
2001-04-11 14:32   ` Andreas Franck
2001-04-11 14:43     ` David Howells
2001-04-11 15:00       ` Andreas Franck
2001-04-11 15:14         ` Bernd Schmidt
2001-04-11 18:27           ` Linus Torvalds
2001-04-12  8:38             ` Jamie Lokier [this message]
2001-04-10 19:42 [PATCH] " Linus Torvalds
2001-04-11 12:57 ` [PATCH] 2nd try: " David Howells

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010412103803.B25536@pcep-jamie.cern.ch \
    --to=lk@tantalophile.demon.co.uk \
    --cc=afranck@gmx.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=andrewm@uow.edu.au \
    --cc=bcrl@redhat.com \
    --cc=bernds@redhat.com \
    --cc=dhowells@cambridge.redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®