657
Subj : Re: [.NET] Volatile Fields
To   : comp.programming.threads
From : David Schwartz
Date : Sun Sep 18 2005 05:38 am


"Cool Guy" <coolguy@abc.xyz> wrote in message 
news:xq3fbvfycufp.dlg@cool.guy.abc.xyz...

> David Schwartz <davids@webmaster.com> wrote:

>>     What do caches have to do with thread-safety? It's read/write 
>> *ordering*
>> that creates thread safety problems, not caches.

> I think I understand it more now -- when you talk of read/write 
> re-ordering
> you're talking about when reads/writes are effectively made to/from **main
> memory**, right?

    No. I'm talking about when they're made by the CPU.

> Before I was thinking it was about *any* and *all* reads/writes being 
> moved
> around.

    There are three things that cause problems for multi-threaded programs 
on typical modern SMP machines:

    1) Instruction re-ordering. This is where the compiler or the processor 
internally performs instructions in a different order from that in the 
high-level code.

    2) Posted writes. This is where the CPU does not output a write to its 
cache immediately but instead puts it in a temporary holding place. (Not the 
L2 cache, but a posted write buffer.)

    3) Speculative fetches. This is where the CPU reads data before it needs 
it and keeps the data for a later instruction.

    The L1 and L2 caches don't even enter into the picture because the cache 
coherency hardware makes them invisible to threads. They are, however, an 
issue for DMA from peripherals because the cache coherency is only between 
the processors.

    DS

.

0