All of lore.kernel.org
 help / color / mirror / Atom feed
From: "R. Sinoradzki" <sinoradz@student.uni-kl.de>
To: Justin Carlson <justincarlson@cmu.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: multithreading  on a multiprocessor system ( a bit OT )
Date: Wed, 16 Jan 2002 22:33:58 +0100	[thread overview]
Message-ID: <3C45F1C6.2010409@student.uni-kl.de> (raw)
In-Reply-To: <3C45D95C.7000402@student.uni-kl.de> <1011212204.314.3.camel@gs256.sp.cs.cmu.edu>

Justin Carlson wrote:

> On Wed, 2002-01-16 at 14:49, R. Sinoradzki wrote:
> 
>>O.K my question:
>>Consider two modern processors that share some data and a lock.
>>The lock may be implemented with something like an atomic test-and-set
>>instruction. Now processor 'A' acquires the lock and works with the data.
>>Processor 'B' also wants to access the data, but internally reorders it's
>>instructions because the instructions seem independent from each other.
>>So 'B' might access the data without having the lock.
>>If it's a single processor system, reordering instructions in a way that
>>ensures that it looks 'as if' everything has been executed in the right order
>>might be easy, but in a multiprocessor system 'A' doesn't know 'B's state.
>>
> 
> Then you've got a bug.  Modern implementations that do SMP provide some
> way of placing barriers around speculative execution structures to make
> sure you don't, say, go out and read some memory location that changes
> state in a device because that's an OK speculative action to take.
> 
> Can't really comment on x86, as I'm not very good with it, but taking
> for example MIPS and Alpha, in addition to the ll-sc ops, there are a
> sync and mb instructions, respectively, which provide a method for
> assuring that previous operations have become visible in terms of
> general machine state before going on.
> 
> -Justin
> 

Ah, thank you for the keywords.
Sorry, I should have searched "multiprocessor synchronization" in Google, but
I tried something else that gave me a lot of useless results ...

Ralf


      reply	other threads:[~2002-01-16 21:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-16 19:49 multithreading on a multiprocessor system ( a bit OT ) R. Sinoradzki
2002-01-16 20:16 ` Justin Carlson
2002-01-16 21:33   ` R. Sinoradzki [this message]

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=3C45F1C6.2010409@student.uni-kl.de \
    --to=sinoradz@student.uni-kl.de \
    --cc=justincarlson@cmu.edu \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.