Atomicity of values isn't something I'd assume happens automatically. Word tearing isn't observable from single threaded code.
I think the only thing you can safely and portably assume is the high level "single threaded observable behavior will occur" statement. It's also interesting to note that "passage of time" isn't one of those observable effects, despite sometimes being THE effect you're after (e.g. crypto). On Tue, Jan 17, 2017 at 4:59 AM 'Nitsan Wakart' via mechanical-sympathy < mechanical-sympathy@googlegroups.com> wrote: > "what about all the encoders/decoders or any program that rely on data > access patterns to pretend to be and remain "fast"?" > There's no problem in reordering while maintaining observable effects, > right? > You should assume a compiler interprets "observable effects" to mean > "order imposed by memory model". Hence Gil's approach reflects this as > "assume nothing" about plain memory access code, except that it will appear > to have executed in program order when it is "observable". You can "cheat" > and observe the effects of "plain access" code as it executes (e.g. read > the mutated memory from another thread, or observe it using a native > debugger), but the compiler is not bound to order what you'll see in any > particular way (hence reordering and eliminating loads/stores etc is fine). > > "how much a developer could rely on the fact that a compiler (or the > underline HW) will respect the memory access that he has put into the code > without using any fences?" > Not at all... OK, just a little bit: > - You can assume program order will magically work out in the end (when > observable) > - You can assume atomicity of values (no word tearing) > That's pretty much it. > For decoders/encoders: > - If you expect the decoded/encoded contents to be read from another > thread you need fences/barriers. > - If you expect the decoded/encoded contents to be read from same thread, > the appearance of program order should sort you out. > > It doesn't half hurt to look at generated code and see if the compiler is > being stupid and try and help it out, but the validity of such an effort > can be very limited in effect (because HW/profile/compiler differences will > lead to nullifying your efforts) > > > > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > email to mechanical-sympathy+unsubscr...@googlegroups.com. > > > For more options, visit https://groups.google.com/d/optout. > > > -- Sent from my phone -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
