multithreading - Can this C# code fail because of a value in a register or cache never getting written back to main memory? -

in article:

http://msdn.microsoft.com/en-us/magazine/jj883956.aspx

the author states following code can fail due "loop read hoisting":

class test {   private bool _flag = true;   public void run()   {     // set _flag false on thread     new thread(() => { _flag = false; }).start();     // poll _flag field until set false     while (_flag) ;     // loop might never terminate!   } } 

in loop read hoisting, compiler may change while loop above following because of single-thread assumption:

if (_flag) { while (true); } 

what i'm wondering this: if compiler doesn't perform optimization, there still potential loop run forever on multiprocessor machine due 1 processor updating _flag in register or cache , never flushing cache memory readable other thread? i've read "c# writes volatile," article linked says not guaranteed ecma spec , things aren't implemented way on arm. i'm trying figure out how paranoid have to write threaded code work on platforms.

here related question:

can c# thread cache value , ignore changes value on other threads?

but think code in accepted answer getting optimized loop read hoisting, proves nothing memory visibility...

if compiler doesn't perform optimization, there still potential loop run forever on multiprocessor machine due 1 processor updating _flag in register or cache , never flushing cache memory readable other thread?

yes.

i've read "c# writes volatile," article linked says not guaranteed ecma spec , things aren't implemented way on arm.

how relevant? main thread isn't writing, it's reading.

i'm trying figure out how paranoid have to write threaded code work on platforms.

it's not paranoia if out you. threading hard. do: leave low-level manipulation of shared memory experts.

write code using highest possible level of abstraction, abstractions written experts. should never write code described, not because it's wrong -- though -- because it's @ wrong level of abstraction. if want represent idea of "this operation can cancelled" use cancellationtoken; that's they're for. if want represent notion of "this work produces result in future", use task<t>; that's they're for. don't try roll own; let microsoft you.

update: more information thread safety in c#, volatile semantics, low-lock techniques, , why should avoid doing of these things yourself, see:

vance's awesome 2005 article on low lock techniques:

http://msdn.microsoft.com/en-us/magazine/cc163715.aspx

my 2011 series of 3 articles begins here:

http://ericlippert.com/2011/05/26/atomicity-volatility-and-immutability-are-different-part-one/

in particular third relevant first 2 might interesting well.

joe duffy reiterates why should not use volatile:

http://joeduffyblog.com/2010/12/04/sayonara-volatile/

my 2014 pair of ask bug guys articles:

http://blog.coverity.com/2014/03/12/can-skip-lock-reading-integer/ http://blog.coverity.com/2014/03/26/reordering-optimizations/

i've given in reasonable reading order; if you're finding vance's article difficult going, try starting three-part series instead , go it.