Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Memory access vs variable access

Reply
Thread Tools

Memory access vs variable access

 
 
gpderetta
Guest
Posts: n/a
 
      06-25-2008
On Jun 25, 3:44*pm, Gerhard Fiedler <(E-Mail Removed)> wrote:
<snip>
> Taken all this together, it seems that on "most modern architectures" cache
> coherency is mostly guaranteed by the hardware, and for example it is not
> necessary to use memory barriers or locks for access to volatile boolean
> variables that are only read or written (never using a read-modify-write
> cycle). Is this correct? What is all this talk about different threads
> seeing values out of order about, if the cache coherency is maintained by
> the hardware in this way?


Cache coherency is not the only part of a system that can reorder load
and stores. Write buffers and OoO machinery are also responsible. Even
x86 which has an otherwise fairly strong memory model, requires for
example StoreLoad memory barriers (i.e. mfence or locked operations).

So, AFAIK the answer is no: in general, and for most compilers, even
volatile is not enough.

--
gpd



 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      06-25-2008
On Jun 25, 3:44 pm, Gerhard Fiedler <(E-Mail Removed)> wrote:
> On 2008-06-25 04:58:41, James Kanze wrote:

[...]
> > For Sparc architecture,
> > seehttp://www.sparc.org/specificationsDocuments.html. I
> > presume that other architecture providers (e.g. Intel, AMD,
> > etc.) have similar pages.


> Thanks. I thought that it would also depend on how the
> compiler generates the code, but I guess you're right in
> assuming that any (halfway decent) compiler will generate
> 8-bit writes for 8-bit variables if that is possible


Well, it would be nice if they'd document it. But in practice,
I don't worry too much about a compiler generating code to load
a word, change one byte of it, and then storing it, if the
hardware has a single instruction byte store.

> >> Also keep in mind that most modern computers use caching.
> >> In a typical case, any read from or write to main memory
> >> happens an entire cache line at a time. Bookkeeping is also
> >> done on the basis of entire cache lines, so the processor
> >> doesn't care how many bits in a cache line have been
> >> modified -- from its viewpoint, the cache line as a whole
> >> is either modified or not. If, for example, another
> >> processor attempts to read memory that falls in that cache
> >> line, the entire line is written to memory before the other
> >> processor can read it. Even if the two are entirely
> >> disjoint, if they fall in the same cache line, the
> >> processor treats them as a unit.


> > That's true to a point. Most modern architectures also
> > ensure cache coherence at the hardware level: if one thread
> > writes to the first byte in a cache line, and a different
> > thread (on a different core) writes to the second byte, the
> > hardware will ensure that both writes eventually end up in
> > main memory; that the write back of the cache line from one
> > core won't overwrite the changes made by the other core.


> Taken all this together, it seems that on "most modern
> architectures" cache coherency is mostly guaranteed by the
> hardware, and for example it is not necessary to use memory
> barriers or locks for access to volatile boolean variables
> that are only read or written (never using a read-modify-write
> cycle). Is this correct? What is all this talk about different
> threads seeing values out of order about, if the cache
> coherency is maintained by the hardware in this way?


Several things. The first, of course, is what we've just been
talking about only concerns a single cache line; the hardware
might not be so careful between cache lines (which results in
multiple physical writes). But the real reason is that reads
and writes, even to the cache, are pipelined in the processor
itself, and can be reordered in the pipeline. Thus, for
example, if we suppose two int's, i and j, both initially 0, and
one processor executes:

store #1, i
store #1, j

a second processor can still see the condition i==0, j==1,
because either the first processor has reordered the writes
(because of pipeline considerations), or because the second
recognized that it already had a read of the cache line with j
in its pipeline, and used the results of that read for j.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
 
 
 
Jerry Coffin
Guest
Posts: n/a
 
      06-25-2008
In article <(E-Mail Removed)>, http://www.velocityreviews.com/forums/(E-Mail Removed)
says...

[ ... ]

> Taken all this together, it seems that on "most modern architectures" cache
> coherency is mostly guaranteed by the hardware, and for example it is not
> necessary to use memory barriers or locks for access to volatile boolean
> variables that are only read or written (never using a read-modify-write
> cycle). Is this correct? What is all this talk about different threads
> seeing values out of order about, if the cache coherency is maintained by
> the hardware in this way?


Yes and no. The hardware normally ensures coherency for a single
variable -- but it doesn't know anything about the relationships you've
established between variables. For example, assume a really simple
situation where you have some data and a bool to tell when the data is
valid:

struct whatever {
int data1;
float data2;
bool valid;
public:
whatever() : valid(false) {}
} thing;

If you have code like:

thing.data1 = 1;
thing.data2 = 2.0f;
thing.valid = true;

The hardware will assure that when a write has taken place to any of the
variables, any other core looking at the memory location of that
variable will see the value that was written.

Now, we don't care at all about the relative order in which data1 and
data2 are written -- whichever way the hardware can do it the fastest is
fine by us. BUT we need to assure that 'valid' is only see as true AFTER
the values have been written to both data1 and data2.

The hardware doesn't know this on its own. It just sees three separate
assignments to three separate variables. As such, the programmer needs
to "inform" the hardware about the relationship involved.

--
Later,
Jerry.

The universe is a figment of its own imagination.
 
Reply With Quote
 
Gerhard Fiedler
Guest
Posts: n/a
 
      06-25-2008
On 2008-06-25 14:56:16, Jerry Coffin wrote:

>> Taken all this together, it seems that on "most modern architectures"
>> cache coherency is mostly guaranteed by the hardware, and for example
>> it is not necessary to use memory barriers or locks for access to
>> volatile boolean variables that are only read or written (never using a
>> read-modify-write cycle). Is this correct? What is all this talk about
>> different threads seeing values out of order about, if the cache
>> coherency is maintained by the hardware in this way?

>
> Yes and no. [Lots of useful stuff snipped.]


Thanks to all who responded in this thread. It has helped me a good deal in
understanding what I can rely on and what not.

Gerhard
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[comp.lang.c.moderated]Re: how to put my structure variable into CPU caches to eliminate main memory page access time? Stefan Ram C Programming 3 04-16-2011 12:58 AM
"Variable variable name" or "variable lvalue" mfglinux Python 11 09-12-2007 03:08 AM
Differences between Sony Memory Stick & memory Stick Pro vs Memory Stick Duo? zxcvar Digital Photography 3 11-28-2004 10:48 PM
Convert Character Variable to Integer Variable Brad Smallridge VHDL 2 11-18-2004 01:56 AM
How do I scope a variable if the variable name contains a variable? David Filmer Perl Misc 19 05-21-2004 03:55 PM



Advertisments