Hi Cory,
On 16/10/09 6:37 PM, Cory Riddell wrote:
Ulrich Hertlein wrote:
...
Yes, CPUs usually have their own caches and data can be different in
the different caches. However, this isn't what synchronization is
solving. This problem (cache coherency) is handled by the hardware.
The reason you need to do locking is because two threads (which may or
may not run on separate cores) might alter the same data in ways so
that the result is no longer sane.
...
I thought cache coherency depended on cues from the software. For
example, acquiring or releasing a mutex forces any pending writes to
complete then flushed the caches, marking a value as volatile prevented
any caching, etc... Is this wrong?
No, a mutex doesn't affect the cache (other than side effects) - the mutex doesn't know
what area of memory (variables) it is locking. It's only there to assure that nooneelse
enters the critical section at the same time.
Marking a variable as 'volatile' means that it's read from memory every time it is
accessed (the compiler won't attempt to read it into a register). The idea is that
someone else (another thread or hardware) might modify the value.
'volatile' an be used in some cases instead of a lock, for example if one thread writes a
bool (to indicate some event) and another thread only reads that value.
Cheers,
/ulrich
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
