2012/8/4 Sean Kelly <[email protected]> > On Aug 1, 2012, at 10:25 AM, Walter Bright <[email protected]> wrote: > > > > To reiterate, this is why I need to know what problem you are trying to > address, rather than going at it from the solution point of view. > > I think the original request was for there to be some way to prevent > compiler optimization of certain plain old loads/stores: > > > On Jul 23, 2012, at 2:28 PM, Alex Rønne Petersen <[email protected]> > wrote: > > > > And further: How are people *really* supposed to prevent compiler > > reordering in modern D2 programs (without using atomics; they are > > expensive and wasteful for this)? > > This can be useful for tuning concurrent algorithms to avoid unnecessary > synchronized operations and also for the occasional store where the > ordering isn't important so much as that it simply be issued at all. Using > DMD, my suggestion would be to use atomicStore!msync.raw, which performs a > plain old store in asm and uses the fact that DMD doesn't optimize across > asm blocks to make the operation behave in the desired manner. But I > believe GDC and LLDC may both optimize more aggressively with respect to > asm code and so this assumption doesn't hold universally. Personally, if I > could be guaranteed that at least specific asm blocks would be treated as > volatile by the compiler in that there's no code movement across them, etc, > then that would probably be enough. > _______________________________________________ > dmd-internals mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/dmd-internals >
shared is supposed to garantee that. volatile is useless in regard to concurency.
_______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
