Subj : Re: [.NET] Memory Barriers
To   : comp.programming.threads
From : David Schwartz
Date : Wed Sep 14 2005 07:05 am


"Cool Guy" <coolguy@abc.xyz> wrote in message 
news:15pgrumbj7w95$.dlg@cool.guy.abc.xyz...

> David Schwartz <davids@webmaster.com> wrote:

>>> In the following code, is it safe to access Test.o in ThreadJob,
>>> considering it's not volatile and no locking is involved in its access?

>>> I think I remember reading that it's okay to do this if the variable is
>>> only *written* to before the worker *reading* thread is created, but I'm
>>> not sure.

>>     When a thread is created, it has a synchronized view of memory with 
>> the
>> thread that created it.

> That sounds good.  If I may ask, is this documented anywhere?

    C# has, to some extent, a documented memory model. Microsoft's .NET 
documentation provides some as well. This is pretty much required behavior 
for any threading library layered on top of C or C++ though. Not having this 
would make some common patterns with no good replacements almost undoable.

    DS

.