Can multiple threads set a global variable simultaneously?

5 views
Skip to first unread message

Dimitris Agrafiotis

unread,
Feb 12, 2002, 9:18:07 PM2/12/02
to
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
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

unread,
Feb 13, 2002, 3:06:46 AM2/13/02
to
Dimitris Agrafiotis <dimi...@3dp.com> wrote:
> 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
Under POSIX, it is undefined what happens unless you do proper memory
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

unread,
Feb 13, 2002, 3:41:37 AM2/13/02
to

josh

unread,
Feb 13, 2002, 11:37:43 AM2/13/02
to
Use InterlockedBlahBlah... functions. Otherwise it can be anything. Don't know on
Posix, suspect the same, probably depending on the processor, but it's intel
you're talking about, I take it.

Alexander Terekhov

unread,
Feb 14, 2002, 8:41:59 AM2/14/02
to
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?

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

unread,
Feb 14, 2002, 10:44:31 AM2/14/02
to
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. I didn't get the rest of your message.

Alexander Terekhov

unread,
Feb 15, 2002, 9:32:35 AM2/15/02
to
josh <jo...@xtreme.net> wrote in message news:<1103_1013701471@js3owsj2-2j2-2j>...

> 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.

josh

unread,
Feb 15, 2002, 3:00:35 PM2/15/02
to
Thanks.
Reply all
Reply to author
Forward
0 new messages