Subj : Re: [x86] simultaneous writes
To   : comp.programming.threads
From : Michael Pryhodko
Date : Thu Mar 31 2005 05:14 pm

> > 1. is it possible that after this different processors will see
> > different values in their caches? As far as I understand cache
> > coherency mechanism will prevent it, right?
>
> Yes.  Cache is tranparent in most cases, meaning that you cannot
> determine whether it exists with testcases such as this since
> the testcase will will behave the same with or without cache.

Well... Currently I am working on interesting MT issue and I found neat
solution for it. But I need some guarantees. I'll try to describe it in
more formal way:
we have N processors, each executes the same program:
write(mem_addr, Ui)
mfence // make value visible to other threads
       // prevent too early read
Ai = read(mem_addr)

- Ui -- unique processor id
- Ai -- processor-local variable (e.g. register)
- mem_addr 4byte aligned, write and read are 4byte (i.e. atomic)
- Initially store buffers empty
- platform -- SMP, x86 (i.e. every processor runs with the same speed)
- mem_addr cached in the every processors cache
- all processors start execution simultaneously

I need guarantee that possible execution outcomes will be only:
{A1, A2, ..., AN} = {Ui, Ui, ... , Ui}, i in [1, N]

Is it true?


If not -- is it will become true if we perform "read" much later? Is it
possible to create a program that will provide this guarantee with
minimum "delay"?


> > 2. how platform decides which value "win"?
>
> Hardware arbitration.  Get a boot on theory and design of hardware.

I think this would be too low-level programming. :)) I do not have SO
much time to spend. Maybe you could give a short description? For
example something like this:
"cache coherency uses serialized mechanism to notify participants, i.e.
if two updates happen simultaneously, one must wait, second update will
overwrite first one (i.e. will "win"). In case of x86 updates generated
by processor with higher id have priority."

Bye.
Sincerely yours, Michael.

.