linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Kalle Pokki <kalle.pokki@iki.fi>
To: linuxppc-embedded <linuxppc-embedded@ozlabs.org>
Subject: PowerPC reservations
Date: Thu, 10 Nov 2005 10:20:30 +0200	[thread overview]
Message-ID: <437302CE.8070309@iki.fi> (raw)

Hi,

Can someone please help me understand how the memory reservations in 
PowerPC actually work. Let's just assume uniprocessor with a pre-emptive 
scheduler, and take a text-book example of an atomic increment case, 
which is also frequently used in e.g. the Linux kernel. With two atomic 
operations, everything seems to be just fine. But how about with three 
concurrent threads of execution?

 From the following code, assume r3 contains the same address for each 
incrementing operation. If the first atomic increment is pre-empted  in 
the middle, execution then jumps to the second increment (by the 
scheduler). The second increment runs through and succeeds, and 
continues straight to the third increment. Then it is again pre-empted 
in the middle, execution returning to the first increment. Now the 
processor has the reservation with the correct address, and the first 
increment succeeds when still holding the original input value. The 
first and the second increment thus write the same value in memory. 
After the first increment, the scheduler again continues the third 
increment, which doesn't succeed a first, but the second round succeeds. 
However, the value in the address pointed by r3 was not increased by 
three, but by two.

Am I just not getting how this is really supposed to work? Are there 
still some other constructs in use to prevent this, e.g. extra stwcx. 
instructions when changing the thread of execution?

I'm also wondering why the architecture specifically defines the stwcx. 
instruction to have, well, undefined behavior in case the reservation 
address differs from the address of the previous lwarx...

1:      lwarx r6, r0, r3
        addi r6, r6, 1
        stwcx. r6, r0, r3
        bne- 1b

.....

2:      lwarx r7, r0, r3
        addi r7, r7, 1
        stwcx. r7, r0, r3
        bne- 2b

3:      lwarx r8, r0, r3
        addi r8, r8, 1
        stwcx. r8, r0, r3
        bne- 3b

             reply	other threads:[~2005-11-10  8:20 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-10  8:20 Kalle Pokki [this message]
2005-11-10 15:20 ` PowerPC reservations Michael R. Zucca

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=437302CE.8070309@iki.fi \
    --to=kalle.pokki@iki.fi \
    --cc=linuxppc-embedded@ozlabs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).