Do I need a memory barrier here?

[JC]

Do I need to insert a memory barrier in the following situation:

x is a global variable;

function1 {
x = 100;
// <--- here?
function2();
}

function2 {
start a new thread at threadproc
}

threadproc {
print x;
}

Am I guaranteed that, after a function call and a new thread starts,
the new thread will see the value of x set in function1? Or do I have
to set a write barrier after x = 100? Specifically, I'm writing in C+
+, on Windows, for x86-compatible platforms.

Thanks,
Jason

[Chris M. Thomasson]

"JC" <jason.c...@gmail.com> wrote in message
news:a98d0d97-8eb0-4d2c...@n10g2000vbl.googlegroups.com...

You don't need a memory barrier if your using pthreads because
`pthread_create()' already acts as an implicit membar for the calling
thread. Windows acts the same way. I would consider it to be a bug if a
threading implementation did not issue a barrier before new threads are
created...

[JC]

On Dec 24, 10:39 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> "JC" <jason.cipri...@gmail.com> wrote in message

Thanks, that's what I was wondering.

What about the compiler; do I have to worry about it reordering the
assignment and function2() call? Or are there some rules in C++ that
state that global variable assignments and function calls can't be
reordered?

Thanks
Jason

[Marcel Müller]

Hi!

Any function call or statemend end (at ';') is a sequence point. That
does not replace the membar, but it ensures that the membar is doing its
work.

Marcel

[JC]

On Dec 26, 12:13 pm, Marcel Müller <news.5.ma...@spamgourmet.com>
wrote:

I see, thanks!

Jason