Is *all* thread cached data flushed at MemoryBarrier

Hi,

I do not understand clearly what is your question. MemoryBarrier (according
to MSDN) is only significative in Itanium processors, not sure if the .net
is even ported to the itanium to be honest.

My suggestion is to try to see what is the equivalent in the unmanaged
world.
--
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

<NO***********@ lycos.comwrote in message
news:11******** **************@ b28g2000cwb.goo glegroups.com.. .

Obviously wrapping a critical section around access to some set of
shared state variables flushes any cached data, etc so that the threads
involved don't see a stale copy. What I was wondering is *what*
exactly gets flushed. Does the compiler some how determine the data
that is accessible from that thread, and flush just that set? (Seems
unlikely to me). Is it all data cached in registers etc? Or am I
overthinking this and instead it's more along the lines that a memory
barrier is just invalidating pages of memory such that when another
thread goes to access that memory it checks first to see if that page
needs to be refetched from main memory?

Thanks for any insights,
Tom

When a lock is performed (or Monitor enetr/exit) in implicit read and
write memory barrier is performed to assure that the current thread
does not look at a "stale" value (one that was in a
cache/register/etc). This is the reason (for example) that you cannot
perform a loop on a simple boolean, waiting for it to be changed by
another thread. The "watching" thread is likely to continue to loop
after the boolean has changed value because it is seeing a stale value.
My question is, when this memory barrier is performed, what is the set
of data that gets flushed or gets invalidated (forcing a readthrough)
or gets written-through, or whatever.

Tom

Ignacio Machin ( .NET/ C# MVP ) wrote:

Hi,

I do not understand clearly what is your question. MemoryBarrier (according
to MSDN) is only significative in Itanium processors, not sure if the .net
is even ported to the itanium to be honest.

My suggestion is to try to see what is the equivalent in the unmanaged
world.
--
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

<NO***********@ lycos.comwrote in message
news:11******** **************@ b28g2000cwb.goo glegroups.com.. .

Obviously wrapping a critical section around access to some set of
shared state variables flushes any cached data, etc so that the threads
involved don't see a stale copy. What I was wondering is *what*
exactly gets flushed. Does the compiler some how determine the data
that is accessible from that thread, and flush just that set? (Seems
unlikely to me). Is it all data cached in registers etc? Or am I
overthinking this and instead it's more along the lines that a memory
barrier is just invalidating pages of memory such that when another
thread goes to access that memory it checks first to see if that page
needs to be refetched from main memory?

Thanks for any insights,
Tom

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

When a lock is performed (or Monitor enetr/exit) in implicit read and
write memory barrier is performed to assure that the current thread
does not look at a "stale" value (one that was in a
cache/register/etc). This is the reason (for example) that you cannot
perform a loop on a simple boolean, waiting for it to be changed by
another thread. The "watching" thread is likely to continue to loop
after the boolean has changed value because it is seeing a stale
value.
My question is, when this memory barrier is performed, what is the set
of data that gets flushed or gets invalidated (forcing a readthrough)
or gets written-through, or whatever.

It's defined by the hardware architecture. In the case of x86, the amount
of memory flushed is 0, becuase x86 processors have strong cache coherency
guarantees. In other architectures it will be different, but in all cases,
following a memory barrier, all writes issued before the barrier will be
visible to all CPUs. Whether that's done by cache invalidation, updating
other caches, etc., is defined by the hardware architecture and generally
not visible to the programmer.

-cd

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

Carl Daniel [VC++ MVP] wrote:

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

When a lock is performed (or Monitor enetr/exit) in implicit read and
write memory barrier is performed to assure that the current thread
does not look at a "stale" value (one that was in a
cache/register/etc). This is the reason (for example) that you cannot
perform a loop on a simple boolean, waiting for it to be changed by
another thread. The "watching" thread is likely to continue to loop
after the boolean has changed value because it is seeing a stale
value.
My question is, when this memory barrier is performed, what is the set
of data that gets flushed or gets invalidated (forcing a readthrough)
or gets written-through, or whatever.

It's defined by the hardware architecture. In the case of x86, the amount
of memory flushed is 0, becuase x86 processors have strong cache coherency
guarantees. In other architectures it will be different, but in all cases,
following a memory barrier, all writes issued before the barrier will be
visible to all CPUs. Whether that's done by cache invalidation, updating
other caches, etc., is defined by the hardware architecture and generally
not visible to the programmer.

-cd

Tom,

I have to ask, why are you using MemoryBarrier instead of the lock
statement?

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

<NO***********@ lycos.comwrote in message
news:11******** **************@ b28g2000cwb.goo glegroups.com.. .

Obviously wrapping a critical section around access to some set of
shared state variables flushes any cached data, etc so that the threads
involved don't see a stale copy. What I was wondering is *what*
exactly gets flushed. Does the compiler some how determine the data
that is accessible from that thread, and flush just that set? (Seems
unlikely to me). Is it all data cached in registers etc? Or am I
overthinking this and instead it's more along the lines that a memory
barrier is just invalidating pages of memory such that when another
thread goes to access that memory it checks first to see if that page
needs to be refetched from main memory?

Thanks for any insights,
Tom

To be honest, the original question was for informational purposes
only.

I one of those people that always wants to know the "why", not just the
"how".

Any place where I am forced to say to myself "I know if I do this it
will work, but I don't really completely know *why* it does" is a place
where I start buying books, downloading articles, and hitting Google.

On this topic, I've found dedicated books on advanced concurreny to be
thin at best in the .NET world. Java on the other, which has a less
feature-rich set of concurrency options, has a number of excellent
texts available. If anyone can recommend a few highly-detailed books
on the topic (NOT books with just a chapter or two on the topic),
please let me know!

Tom
Nicholas Paldino [.NET/C# MVP] wrote:

Tom,

I have to ask, why are you using MemoryBarrier instead of the lock
statement?

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

<NO***********@ lycos.comwrote in message
news:11******** **************@ b28g2000cwb.goo glegroups.com.. .

Obviously wrapping a critical section around access to some set of
shared state variables flushes any cached data, etc so that the threads
involved don't see a stale copy. What I was wondering is *what*
exactly gets flushed. Does the compiler some how determine the data
that is accessible from that thread, and flush just that set? (Seems
unlikely to me). Is it all data cached in registers etc? Or am I
overthinking this and instead it's more along the lines that a memory
barrier is just invalidating pages of memory such that when another
thread goes to access that memory it checks first to see if that page
needs to be refetched from main memory?

Thanks for any insights,
Tom

Tom,

While I can't really recommend any FULL books on the topic, I can tell
you that for the most part, you will want to use the lock statement (which
in turn is really a call to Monitor.Enter/Monitor.Exit) over MemoryBarrier.
Monitor.Enter/Monitor.Exit is specified in the spec as having to work, and
you should always be able to depend on that.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

<NO***********@ lycos.comwrote in message
news:11******** **************@ 75g2000cwc.goog legroups.com...

To be honest, the original question was for informational purposes
only.

I one of those people that always wants to know the "why", not just the
"how".

Any place where I am forced to say to myself "I know if I do this it
will work, but I don't really completely know *why* it does" is a place
where I start buying books, downloading articles, and hitting Google.

On this topic, I've found dedicated books on advanced concurreny to be
thin at best in the .NET world. Java on the other, which has a less
feature-rich set of concurrency options, has a number of excellent
texts available. If anyone can recommend a few highly-detailed books
on the topic (NOT books with just a chapter or two on the topic),
please let me know!

Tom
Nicholas Paldino [.NET/C# MVP] wrote:

>Tom,

I have to ask, why are you using MemoryBarrier instead of the lock
statement?

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

<NO*********** @lycos.comwrote in message
news:11******* *************** @b28g2000cwb.go oglegroups.com. ..

Obviously wrapping a critical section around access to some set of
shared state variables flushes any cached data, etc so that the threads
involved don't see a stale copy. What I was wondering is *what*
exactly gets flushed. Does the compiler some how determine the data
that is accessible from that thread, and flush just that set? (Seems
unlikely to me). Is it all data cached in registers etc? Or am I
overthinking this and instead it's more along the lines that a memory
barrier is just invalidating pages of memory such that when another
thread goes to access that memory it checks first to see if that page
needs to be refetched from main memory?

Thanks for any insights,
Tom

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

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

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.

Reordering *is* an issue, however. Memory barriers are about preventing
*effective* reordering, whether that's done by the JIT or due to caches
etc.

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