Re: How to make this program more efficient?

From:

peter koch <peter.koch.larsen@gmail.com>

Newsgroups:

comp.lang.c++

Date:

Tue, 23 Sep 2008 12:28:36 -0700 (PDT)

Message-ID:

<ad789ebb-76c7-4d64-8232-b7caa7723234@e53g2000hsa.googlegroups.com>

On 23 Sep., 21:27, Jon Harrop <j...@ffconsultancy.com> wrote:

courp...@gmail.com wrote:

On 23 sep, 03:26, Jon Harrop <j...@ffconsultancy.com> wrote:

[...]

I say you will not and that you need a memory barrier writing the
pointer (and nothing more).

Assuming you mean "deterministic" when you say "consistent", I think you
are wrong. Even if both the reader and writer lock the pointer (which is
pointless if the operations are already atomic) there is still a race
condition. Specifically, the reader (thread 2) might read either the old
or new value.

You still make a confusion between locks and memory barriers.

Sorry: I read "synchronization" and assumed Peter was referring to locks.

Well - I can speak for myself and did not mean locks - simply
synchronisation.

You have to take care about the memory ordering problem, at least on
SMP architectures...

Yes.

In your set function, without the locks, the intructions can be
reordered either at runtime on a SMP architecture or by the compiler.

Does my use of the "volatile" keyword not prohibit that?

I don't believe so. Extensions might give stricter guarantees (and
Microsoft does so, if I understand correctly).
But volatile is not needed as long as you have a memory barrier on the
pointer. If the pointer is written using "normal" means your code is
still not guaranteed to be visible only after all parts of the
structure has been written.

/Peter