> concern is corruption of the data or core dump. In my application, it
> is perfectly legal if one thread simply overrides the value set by the
> other threads. I do not want to synchronize the threads to ensure that
> there is no corruption, because this will seriously degrade the
> performance of my algorithm. Thanks in advance.
Have you tested and found that the locking actually did degrade performance?
Write correct code first, optimized code second.
What is it tha you are actually trying to do?
--
Arnold Hendriks <a.hen...@b-lex.com>
B-Lex Information Technologies, http://www.b-lex.com/
http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap04.html#tag_04_10
http://groups.google.com/groups?as_umsgid=GporLu.ouG%40Watt.COM
http://groups.google.com/groups?as_umsgid=3C628158.69EA424F%40web.de
(see "Intel does not guarantee that future processors..." section)
regards,
alexander.
Well, but *what* (if any) MEMORY SYNCHRONIZATION semantics do they
provide?
ACQUIRE (mutex.lock)?
RELEASE (mutex.unlock)?
ACQUIRE-RELEASE (both)?
Something else?
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/synchro_11df.asp
Does NOT look very convincing to me!
("Processors can be instructed to force their memory
caches to agree with main memory..." w.r.t mem.sync
IS JUST PLAIN MS-STYLE-BULLSHIT, AFAIK/AFAICT/IMHO!)
regards,
alexander.
That's rather easy to comprehend... but there are VISIBILITY
issues w.r.t to DEPENDENT objects/data as well:
> I didn't get the rest of your message.
Read this:
http://www.primenet.com/~jakubik/mpsafe/MultiprocessorSafe.pdf
"Relaxed multiprocessor memory models..." -- think of IA64/Windows,
for example, if you just refuse to accept the Intel's lack
of strong/processor ordering guarantees w.r.t to future IA32
multiprocessors... despite the fact that IA32 ALREADY has
memory barriers/fence instructions:
"11.4.4.3. MEMORY ORDERING INSTRUCTIONS
The SSE2 extensions introduce two new fence instructions
(LFENCE and MFENCE) as companions to the SFENCE instruction
introduced with the SSE extensions. The LFENCE instruction
establishes a memory fence for loads. It guarantees ordering
between two loads and prevents speculative loads from passing
the load fence (that is, no speculative loads are allowed
until all loads specified before the load fence have been
carried out).
The MFENCE instruction combines the functions of the LFENCE
and SFENCE instructions by establishing a memory fence for
both loads and stores. It guarantees that all loads and stores
specified before the fence are globally observable prior to any
loads or stores being carried out after the fence."
Also, you might want to read this:
http://altair.cs.oswego.edu/pipermail/concurrency-interest/2002-February/000023.html
http://altair.cs.oswego.edu/pipermail/concurrency-interest/2002-February/000024.html
http://groups.yahoo.com/group/Boost-Users/message/278
(atomic operations and ref.counting/thread_shared_ptr)
regards,
alexander.