Re: Memory access vs variable access
On Jun 24, 3:48 pm, Gerhard Fiedler <geli...@gmail.com> wrote:
I'm not sure whether this is a problem or not, or how to
determine whether it is one.
It's potentially one.
Say memory access (read and write) happens in 64-bit chunks,
and I'm looking at 32-bit variables. This would mean that
either some other variable is also written when writing a
32-bit variable (which means that all access to 32-bit
variables is of the read-modify-write type, affecting some
other variable also), or that all 32-bit variables are stored
in their own 64-bit chunk.
With single-threaded applications, that's a mere performance
question. But with multi-threaded applications, there's no way
I can imagine that would avoid the read-modify-write problems
the first alternative would create, as it is nowhere defined
what the other variable is that is also written -- so it can't
be protected by a lock. Without it being protected by a lock,
there's nothing that prevents a thread from altering it while
it is in the middle of the read-modify-write cycle, which
means that the end of it will overwrite the altered value with
the old value.
However, there must be a way to deal with this, otherwise
multi-threaded applications in C++ wouldn't be possible.
Most hardware provides for single byte writes (even when the
read is always 64 bits), and takes care that it works correctly.
=46rom what I understand, this wasn't the case on some early DEC
Alphas, and it certainly wasn't the case on many older
platforms, where when you wrote a byte, the hardware would read
a word, and rewrite it.
The upcoming version of the standard will address this problem;
if nothing changes, it will require that *most* accesses to a
single "object" work. (The major exception is bit fields. If
you access an object that is declared as a bit field, and any
other thread may modify any object in the containing class, you
need to explicitly synchronize.) Implementations for processors
where the hardware doesn't support this have their work cut out
for them (but better them than us), and byte accesses on such
implementations are likely to be very slow.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34