Casting something as const doesn't automatically make a section of
memory synchronized. In the end it's a compiler hint and doesn't
change the fact the data is still going to live in the same RAM and
cpu caches as everything else.
Also, cache/data coherency is an industry accepted standard (maybe
even a requirement now by vendors) with multiprocessing. Without it
the CPUs will have to force cache commits very frequently and in the
correct ordering, especially for something like a spin lock or context
switch. This would greatly degrade performance and would frankly be
something of a hack to make two non-compliant processors work
together. I can't imagine how properly committing a cache line would
even work when part of the line contains old data.
Cache coherency is usually done through bus snooping or a directory
system to ensure that loading a memory operand will get the correct
mutation even if it lives on another CPU's cache. Some architectures
like the Intel Core use special bus features to enforce data coherency
(avoiding traditional cache coherency methods). This all happens
transparently to the program.
Because of cache/data coherency adherence, after the data has been
stored to cache or main memory, multiple processors can immediately
load the same address without the need for program locking and
retrieve consistent values. Therefore after data has been stored
(written), it can be loaded (read) from main memory or a cache by
multiple processors in any order, at any time, and get the same value
each time.
I suggest reading up on cache coherency and checking out protocols
like MERSI to see how data coherency is maintained on multiprocessor
architectures. Also the IBM 750 series (G3) struggle to become SMP
compliant. It might help anyone who reads and understands it to
choose when locking is necessary and when it's not. There's nothing
wrong with over locking, but performance will needlessly suffer.
On May 8, 2008, at 9:33 AM, Scott Ribe wrote:
No, not exactly, because you know that str is constant and its value
is set
at load time, so multiple readers without locks will be safe.
However, what he was responding to was much more broad, and not
correct:
When was the data written? Unless you're dealing with const data,
then you
still require synchronization primitives ON THE READS, to make sure
that the
cache of the processor executing the reads is refreshed from main
memory as
needed. Unless, of course, you know the exact details of the processor
you're running on and that this is not necessary.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
