ARM bare-metal programming in D (cont) - volatile

Johannes Pfau nospam at example.com
Fri Oct 25 11:08:28 PDT 2013


Am Thu, 24 Oct 2013 21:28:45 +0100
schrieb Iain Buclaw <ibuclaw at ubuntu.com>:

> On 24 October 2013 18:49, Johannes Pfau <nospam at example.com> wrote:
> > Am Thu, 24 Oct 2013 14:04:44 +0100
> > schrieb Iain Buclaw <ibuclaw at ubuntu.com>:
> >
> >> On 24 October 2013 12:10, John Colvin
> >> <john.loughran.colvin at gmail.com> wrote:
> >> > On Thursday, 24 October 2013 at 09:43:51 UTC, Iain Buclaw wrote:
> >> >>>>
> >> >>>> 'shared' guarantees that all reads and writes specified in
> >> >>>> source code happen in the exact order specified with no
> >> >>>> omissions
> >
> > Does this include writes to non-shared data? For example:
> > ------------------------------------
> > shared int x;
> > int y;
> >
> > void func()
> > {
> >     x = 0;
> >     y = 3;  //Can the compiler move this assignment?
> >     x = 1;
> > }
> > ------------------------------------
> >
> 
> Yes, reordering may occur so long as the compiler does not change
> behaviour in respect to the programs sequential points in the
> application.  (Your example, for instance, can not possibly be
> re-ordered).
> 
> It is also worth noting while you may have guarantee of this, it does
> not mean that you can go using __thread data without memory barriers.
> (For instance, if you have an asynchronous signal handler, it may
> alter the __thread'ed data at any point in the sequential program).
> 
> 
> 
> > So there's no additional overhead (in code / instructions emitted)
> > when using shared instead of volatile in code like this? And this
> > is valid code with shared (assuming reading/assigning to x is
> > atomic)? ------------------------------------
> > volatile bool x = false;
> >
> > void waitForX()
> > {
> >     while(!x){}
> > }
> >
> > __interrupt(X) void x_interrupt()
> > {
> >     x = true;
> > }
> > ------------------------------------
> 
> That is correct. :o)
> 
> 
> Regards

Sounds good. Now this should be the standard defined behaviour for
all compilers. But I guess it'll take some more time till the shared
design is really finalized.


More information about the Digitalmars-d mailing list