[concurrency-interest] visibility vs. cache coherency

Joseph Seigh jseigh_cp00 at xemaps.com
Wed Mar 12 07:24:49 EDT 2008


R Samuel Klatchko wrote:
>
> David-
>
> Sorry, I didn't explain myself well.  It's not that I don't care about 
> ordering and latency; rather, I am just trying to understand why 
> things happen and believe I already understand what causes 
> ordering/latency issues.  But I was always baffled by why visibility 
> problems could occur (other then visibility problems caused by 
> compiler/VM optimizations) with cache coherency (everything I have 
> found and read so far on cache coherency not only focus on hardware 
> based, but don't even mention software directed coherency).

Most cache implementations are transparent, meaning you can't detect the 
presence of cache except
for performance effects.  It may be that the memory model has build into 
it some observable effects
of cache such as allowing reads of stale data but you'd have a lot of 
work factoring out the differences
in behavior w/ and w/o cache.

It only matters if you're implementing synchronization constructs.  If 
you're doing that then you
need to know what you're doing and I don't mean the memory model but 
what the actual
synchronization guarantees are.  The latter is a bit difficult since 
there aren't exactly a lot of
formal definitions of synchronization laying about that you can work off of.

--
Joe Seigh


More information about the Concurrency-interest mailing list