Is *all* thread cached data flushed at MemoryBarrier

Brian Gideon <br*********@ya hoo.comwrote:

Maybe I'm wrong, but as I understand it the x86 memory model only
guarentees that writes cannot move with respect to other writes, but it
doesn't make any guarentees about reads. So it seems to me that you're
example is unsafe. But, I bet you'd have a hard time reproducing the
issue in reality. You'd almost certainly have to have a SMP system to
see it.

I thought that, but it's very easy to see "effective" memory read moves
- where a value is basically only read once instead of being reread
each time through a loop:

using System;
using System.Threadin g;

public class Test
{
static volatile bool stop;

static void Main()
{
ThreadStart job = new ThreadStart(Thr eadJob);
Thread thread = new Thread(job);
thread.Start();

// Let the thread start running
Thread.Sleep(50 0);

// Now tell it to stop counting
stop = true;

thread.Join();
}

static void ThreadJob()
{
int count=0;
while (!stop)
{
count++;

}
}
}

That stops half a second after you start it. Take the "volatile" bit
out, and it'll run forever (at least it does on my single processor P4,
when compiled with optimisation enabled).

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Jon Skeet [C# MVP] wrote:

Brian Gideon <br*********@ya hoo.comwrote:

>Maybe I'm wrong, but as I understand it the x86 memory model only
guarentees that writes cannot move with respect to other writes, but
it doesn't make any guarentees about reads. So it seems to me that
you're example is unsafe. But, I bet you'd have a hard time
reproducing the issue in reality. You'd almost certainly have to
have a SMP system to see it.

I thought that, but it's very easy to see "effective" memory read
moves
- where a value is basically only read once instead of being reread
each time through a loop:

using System;
using System.Threadin g;

public class Test
{
static volatile bool stop;

static void Main()
{
ThreadStart job = new ThreadStart(Thr eadJob);
Thread thread = new Thread(job);
thread.Start();

// Let the thread start running
Thread.Sleep(50 0);

// Now tell it to stop counting
stop = true;

thread.Join();
}

static void ThreadJob()
{
int count=0;
while (!stop)
{
count++;

}
}
}

That stops half a second after you start it. Take the "volatile" bit
out, and it'll run forever (at least it does on my single processor
P4, when compiled with optimisation enabled).

But this is just due to code hoisting by the JIT and has nothing to do with
the memory model at the CLR or CPU level. The volatile modifier inhibits
the hoising of the read out of the loop, so the thread stops like you'd
expect. Without voliatile, the read is hoisted and the variable only read
once, since the compiler can easily prove that nothing in the loop affects
the value of the variable.

-cd

Carl Daniel [VC++ MVP]
<cp************ *************** **@mvps.org.nos pamwrote:

<snip>

That stops half a second after you start it. Take the "volatile" bit
out, and it'll run forever (at least it does on my single processor
P4, when compiled with optimisation enabled).

But this is just due to code hoisting by the JIT and has nothing to do with
the memory model at the CLR or CPU level. The volatile modifier inhibits
the hoising of the read out of the loop, so the thread stops like you'd
expect. Without voliatile, the read is hoisted and the variable only read
once, since the compiler can easily prove that nothing in the loop affects
the value of the variable.

But it's the memory model which specifies what the JIT can do. That's
what I'm saying - regardless of CPU architecture, the JIT can do
optimisations which change the "apparent" read time of a variable. The
optimisations it's able to do are controlled by the memory model at the
CLR level.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

First off, thanks to everyone contributing to the thread...this is why
I post here!

I have never used MemoryBarrior in any code other than tests for my own
education, as I said the original question was more theoritcal.

By the way, I have seen caching/reordering (it's often hard to
effectively tell which) in common environments.

This is kind of what I was investiagting. While I am well aware of
"how" to prevent it (and I of course do so), I wanted to know more
about what was going on under the covers.

And the fact that a simple question on the underlying behavior of a
memory barrier has blossomed into this debate on behavior only
underlines what I was saying before. There seems to be nothing
authoratative out there on this topic. If there us room for debate,
then there is room for error and misunderstandin g.

As an example of what I'd like see, I do a lot of p/invoke and COM
interop and the text ".NET and COM - The Complete Interoperabiliy
Guide" is my idea of a great book on that topic. I can only hope such
a volume is created in regards to concurency on the .NET / Windows
platform.

Thanks again,
Tom

Brian Gideon wrote:

Tom,

No, I do not believe it is safe. And even if it technically were I
certainly wouldn't bank on it because you may later port the code to
another framework version or hardware platform.

Maybe I'm wrong, but as I understand it the x86 memory model only
guarentees that writes cannot move with respect to other writes, but it
doesn't make any guarentees about reads. So it seems to me that you're
example is unsafe. But, I bet you'd have a hard time reproducing the
issue in reality. You'd almost certainly have to have a SMP system to
see it.

Here are some excellent links regarding memory barriers the .NET
framework.

<http://blogs.msdn.com/cbrumme/archive/2003/05/17/51445.aspx>
<http://discuss.develop .com/archives/wa.exe?A2=ind02 03B&L=DOTNET&P= R375>
<http://www.yoda.arachs ys.com/csharp/threads/volatility.shtm l>
<http://msdn.microsoft. com/msdnmag/issues/05/10/MemoryModels/>

Brian

NO***********@l ycos.com wrote:

OK.

So my example of watching a boolean is only unsafe on x86 if
instrucution (re)ordering is an issue, not because multiple threads
will see different values for that variable.

That's wasn't completely clear to me before.

Thanks!
Tom

Jon wrote:

That stops half a second after you start it. Take the "volatile" bit
out, and it'll run forever (at least it does on my single processor P4,
when compiled with optimisation enabled).

Which framework version were you using? I tried it with 1.1 and 2.0 on
my dual core laptop and I could only see it run forever with 2.0. I
guess 2.0 is more aggressive in its optimizations. At the very least
this proves that those who naively rely on it being safe in 1.1 will
get burned when they port their code to 2.0.

Brian Gideon wrote:

Jon wrote:

That stops half a second after you start it. Take the "volatile" bit
out, and it'll run forever (at least it does on my single processor P4,
when compiled with optimisation enabled).

Which framework version were you using? I tried it with 1.1 and 2.0 on
my dual core laptop and I could only see it run forever with 2.0. I
guess 2.0 is more aggressive in its optimizations. At the very least
this proves that those who naively rely on it being safe in 1.1 will
get burned when they port their code to 2.0.

I only tried it with 2.0 yesterday, but I think I've tried similar
programs with 1.1 before. I wouldn't like to swear to it though...

Jon

Tom,

One thing I should point out, which Jon already eluded to, is that we
code using the CLR memory model. The hardware memory model is mostly
irrelevant from a .NET developer's perspective because the CLR sits on
top of it. So your example is certainly unsafe because the CLR
specification says it is. We shouldn't be too concerned with the
differences between x86, AMD64, IA64, etc. architectures. That's the
job of the CLR. But, I do share your interest in learning exactly what
is going on behind the scenes.

Brian

NO***********@l ycos.com wrote:

OK.

So my example of watching a boolean is only unsafe on x86 if
instrucution (re)ordering is an issue, not because multiple threads
will see different values for that variable.

That's wasn't completely clear to me before.

Thanks!
Tom

This little sample shows reordering (or some type of caching) on 1.1:
class ConcurrencyTest
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main(string[] args)
{

ConcurrencyTest test = new ConcurrencyTest ();
test.Start();

}

private uint m_First;
private uint m_Second;
private System.Threadin g.Thread m_Incrementor;
private System.Threadin g.Thread m_Inspector;

public void Start()
{

Console.WriteLi ne("Tets running");

m_Incrementor = new Thread(new ThreadStart(Inc rement));
m_Inspector = new Thread(new ThreadStart(Che ckValues));
m_Incrementor.S tart();
m_Inspector.Sta rt();

}

private void Increment()
{
while(true)
{
m_First++;
m_Second++;
}
}

private void CheckValues()
{
while(true)
{

uint first = m_First ;
uint second = m_Second;

if (first < second)
{
Console.WriteLi ne("First is {0} and Second is {1}", first,second);
Thread.Sleep(10 00);
}

}

}
}


Jon Skeet [C# MVP] wrote:

Brian Gideon wrote:

Jon wrote:

That stops half a second after you start it. Take the "volatile" bit
out, and it'll run forever (at least it does on my single processor P4,
when compiled with optimisation enabled).

Which framework version were you using? I tried it with 1.1 and 2.0 on
my dual core laptop and I could only see it run forever with 2.0. I
guess 2.0 is more aggressive in its optimizations. At the very least
this proves that those who naively rely on it being safe in 1.1 will
get burned when they port their code to 2.0.

I only tried it with 2.0 yesterday, but I think I've tried similar
programs with 1.1 before. I wouldn't like to swear to it though...

Jon

NO***********@l ycos.com wrote:

This little sample shows reordering (or some type of caching) on 1.1:

I don't think so. It would be masked by the race condition between the
reads of m_First and m_Second. m_First could be read and m_Second
incremented several times before it is eventually read.

<NO***********@ lycos.comwrote:

This little sample shows reordering (or some type of caching) on 1.1:

I don't see anything - what do you see?

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too