From: Dan Malek <dan@embeddededge.com>
To: Tom Rini <trini@kernel.crashing.org>
Cc: Wolfgang Denk <wd@denx.de>, linuxppc-embedded@lists.linuxppc.org
Subject: Re: linuxppc_2_4_devel patch: 8xx FEC extensions
Date: Thu, 02 Jan 2003 12:40:13 -0500 [thread overview]
Message-ID: <3E14797D.5050605@embeddededge.com> (raw)
In-Reply-To: 20021231155241.GA12063@opus.bloom.county
Tom Rini wrote:
> Erm. That sounds bad. So the values can change under the functions
> feet? Even if the values tested for are only tested by this function,
> that still sounds like a bad idea.
If you look at the code, you will notice that the object that is declared
volatile is part of a shared driver data structure. It isn't a hardware
register. The reason it was originally declared volatile (and is a valid
programming method) was the MII interrupt would set this value, and later
a normal thread of execution would read this value in another function.
These functions can, which is also a valid compiler optimization technique,
cache these global values in a processor register. In order for the normal
thread of execution to see the update from the interrupt handler, you have
to do something to force it to use the shared data structure, not the
optimization. It's no big deal, and quite a common multithreaded programming
practice.
I don't understand Wolfgang's original "multiple access" comment since it's
only accessing a data structure in memory, unless there was some weird software
timing that occurred here due to the additional memory accesses. There shouldn't
be any race conditions even though the status is updated in multiple C program
statements.
Thanks.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2003-01-02 17:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-20 1:05 linuxppc_2_4_devel patch: 8xx FEC extensions Wolfgang Denk
2002-12-23 15:12 ` Tom Rini
2002-12-28 0:27 ` Wolfgang Denk
2002-12-30 15:29 ` Tom Rini
2002-12-30 16:26 ` Wolfgang Denk
2002-12-30 18:12 ` Tom Rini
[not found] ` <3E10EF1C.5040505@embeddededge.com>
[not found] ` <20021231155241.GA12063@opus.bloom.county>
[not found] ` <20021231155839.6D6F8C6139@atlas.denx.de>
2002-12-31 16:13 ` Tom Rini
2003-01-02 17:40 ` Wolfgang Denk
[not found] ` <3E1480E6.4010802@embeddededge.com>
2003-01-02 18:21 ` Tom Rini
[not found] ` <3E1484D9.6070402@embeddededge.com>
2003-01-03 15:47 ` Tom Rini
2003-01-02 17:40 ` Dan Malek [this message]
2003-01-03 22:46 ` Paul Mackerras
2003-01-03 23:01 ` Dan Malek
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=3E14797D.5050605@embeddededge.com \
--to=dan@embeddededge.com \
--cc=linuxppc-embedded@lists.linuxppc.org \
--cc=trini@kernel.crashing.org \
--cc=wd@denx.de \
/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.