Re: Lock variables between two threads
"Ben Voigt [C++ MVP]" <rbv@nospam.nospam> wrote in message
news:u7a$GN7ZJHA.4520@TK2MSFTNGP06.phx.gbl
I was just pointing out that changing a byte potentially requires:
Reading a cache line from main memory (since the memory controller
interface is umpteen bytes wide and doesn't support smaller
transfers). Modifying one byte in the cache line.
Writing the cache line back to main memory.
I'd like to add a data point to this fascinating discussion. The C++0x
draft standard gets around to describe C++ memory model in the presence
of multiple threads. This is what it has to say:
1.7p3 A memory location is either an object of scalar type or a maximal
sequence of adjacent bit-fields all having non-zero width... Two threads
of execution can update and access separate memory locations without
interfering with each other.
1.7p5 [ Example: A structure declared as
struct {
char a;
int b:5,
c:11,
:0,
d:8;
struct {int ee:8;} e;
}
contains four separate memory locations: The field a and bit-fields d
and e.ee are each separate memory locations, and can be modified
concurrently without interfering with each other. The bit-fields b and c
together constitute the fourth memory location. The bit-fields b and c
cannot be concurrently modified, but b and a, for example, can be. -end
example ]
Basically, the standard will require that the hardware a C++ program
runs on be capable of writing a single byte (more precisely, a char)
without interfering with any other, even adjacent, bytes. I can only
assume that current hardware does provide such a capability (since I'd
like to believe the standardization committee knows what they are
doing).
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925