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

Iain Buclaw ibuclaw at ubuntu.com
Thu Oct 24 13:28:45 PDT 2013


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
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';


More information about the Digitalmars-d mailing list