[dmd-internals] Regarding deprecation of volatile statements

[deadal nix]

2012/8/4 Sean Kelly <sean at invisibleduck.org>

> On Aug 1, 2012, at 10:25 AM, Walter Bright <walter at digitalmars.com> 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 <xtzgzorex at gmail.com>
> 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
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>

shared is supposed to garantee that. volatile is useless in regard to
concurency.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20120807/4676ebee/attachment.html>