Am Thu, 24 Oct 2013 21:28:45 +0100 schrieb Iain Buclaw <[email protected]>:
> On 24 October 2013 18:49, Johannes Pfau <[email protected]> wrote: > > Am Thu, 24 Oct 2013 14:04:44 +0100 > > schrieb Iain Buclaw <[email protected]>: > > > >> On 24 October 2013 12:10, John Colvin > >> <[email protected]> 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.
