Re: Only reading of variable vs. thread synchronisation
"Helge Kruse" <Helge.Kruse-nospam@gmx.net> wrote in message
news:48491d34$0$27450$9b4e6d93@newsspool4.arcor-online.net...
"James Kanze" <james.kanze@gmail.com> wrote in message
news:464682ca-4575-4bf2-90b8-a792c2312b5e@k13g2000hse.googlegroups.com...
[...]
You disagree with Posix?
No, never wrote this, I never cited Posix. I disagree that the single
memory access is irrelevant. The fact if you have single memory access it
determines the robustness of the read operation.
With a single memory access it is just impossible that the problem I
described.
The compiler defines how data is stored. The statement, if a
variable is in a single word is compiler and CPU dependend.
But you can know.
For a given compiler, on a given machine, you can sometimes
know.
You're right. But that's not "something you really can't know". Well, you
said you can know.
But it's irrelevant. Even if the variable is in a single
machine word, you need external synchronization.
If a read operation is in a single memory read operation, what do you want
to synchronize?
May be misunderstanding you, but some algorihtms require a membar after a
read. For instance, take a classic single-producer/multi-consumer problem:
static atomicword data = 0;
static atomicword flag = 0;
Producer Thread
-------------------
ATOMIC_STORE(&data, 123);
ATOMIC_STORE(&flag, 1);
Consumer Threads
-------------------
while (! ATOMIC_LOAD(&flag)) {
sched_yield();
}
assert(ATOMIC_LOAD(&data) == 123);
The above has a major race-condition such that the store to the `flag' can
be hoisted up above the store to the `data'; the assertion _may_ fail. You
need memory synchronization on both the producer and consumer side to
properly solve this problem. Here is an example using SPARC memory barriers:
static atomicword data = 0;
static atomicword flag = 0;
Producer Thread
-------------------
ATOMIC_STORE(&data, 123);
MEMBAR #StoreStore;
ATOMIC_STORE(&flag, 1);
Consumer Threads
-------------------
for (;;) {
atomicword const _flag = ATOMIC_LOAD(&flag);
MEMBAR #LoadLoad;
if (_flag) { break; }
sched_yield();
}
assert(ATOMIC_LOAD(&data) == 123);
No we are assured that the store to `data' is rendered visible _before_ the
store to `flag'. And we know that the load from `flag' will not be reordered
wrt the subsequent load from `data'; the assertion is guaranteed to pass.
Memory barriers along with atomic operations are an essential aspect to
low-level concurrent programming techniques...
[...]