[Interest] Heavily Commented Example: Simple Single Frontend with Two BackendsHi,

[K. Frank]

Hello Thiago!

I still don't follow exactly what you are saying.

On Wed, Oct 24, 2012 at 10:56 AM, Thiago Macieira
<thiago.macieira at intel.com> wrote:
> On terça-feira, 23 de outubro de 2012 17.19.13, Thiago Macieira wrote:
>> Well, that's not exactly how processors work. CPU A will eventually get to
>> write the data from its cache back to main RAM. And CPU B will eventually
>> get  to notice that and discard its cache. So the code running on CPU B
>> will eventually get to see the new value.
>>
>> The question is only how long that might take.
>
> Actually, I take this back too.

I'm confused.  Which part are you taking back?  That CPU B will
see the new value?  Or that there is a question about how long
it will take?  (Or both?)

> There's no instruction to make the CPU flush the caches sooner, at least not
> one that programs usually use. Same thing on the other end: no instruction to
> make a load faster.

It sounds like you're saying that in "normal code," nothing will explicitly
flush the cache to main memory or refresh it from main memory.

> So the code that the compiler generates is probably fine.

But for the code to be fine, CPU A's cache must, at some point, get
flushed to main memory, and CPU B's cache must get refreshed from
main memory (or a mutually shared secondary cache).  Sorry for not
understanding what you're saying.

> All you need to do is ensure that it *does* generate the load.

Again, to belabor the question, suppose the compiler does generate
the load of the stop flag (i.e., the read of the stop flag from its memory
address -- which might be cached -- is not optimized away).  What,
in principle, prevents the thread whose loop polls the stop flag from
just sitting on CPU B (never, because of odd luck, being context
switched off of CPU B), and repeatedly reading the stale stop flag from
CPU B's cache?

Now, in practice, it's highly unlikely that CPU B won't ever refresh its
cache or that the stop-flag-polling thread won't ever be context switched
onto a core with an up-to-date cache, but isn't it in principle possible
for the flag-polling thread to keep reading the stale value of the stop
flag, and run forever, even though some other thread set the stop flag
to true?

> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center

Thanks again.  I appreciate your analysis of these issues.


K. Frank