Can multiple threads set a global variable simultaneously?
Dimitris Agrafiotis
variable simultaneously? Is one of the values going to overwrite the
others, or is the value going to be corrupted? I am interested in the
bahavior under both POSIX and NT (Win 2000) threads. Actually, my main
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.
Arnold Hendriks
> What will happen if multiple threads try to set the same global
> variable simultaneously? Is one of the values going to overwrite the
> others, or is the value going to be corrupted? I am interested in the
> bahavior under both POSIX and NT (Win 2000) threads. Actually, my main
synchronization (using eg. mutexes). NT gives you a few more atomicity
guarantees, but they are useless most of the time so you should synchronize
on NT as well.
> 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/
Alexander Terekhov
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.
josh
Posix, suspect the same, probably depending on the processor, but it's intel
you're talking about, I take it.
Alexander Terekhov
> Use InterlockedBlahBlah... functions.
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.
josh
> josh <jo...@xtreme.net> wrote in message news:<1108_1013618263@js3owsj2-2j2-
2j>...
> > Use InterlockedBlahBlah... functions.
>
> Well, but *what* (if any) MEMORY SYNCHRONIZATION semantics do they
> provide?
Alexander Terekhov
> On 14 Feb 2002 05:41:59 -0800, tere...@web.de (Alexander Terekhov) wrote:
> > josh <jo...@xtreme.net> wrote in message news:<1108_1013618263@js3owsj2-2j2-
> 2j>...
> > > Use InterlockedBlahBlah... functions.
> >
> > Well, but *what* (if any) MEMORY SYNCHRONIZATION semantics do they
> > provide?
> Atomic updates.
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.