On Tue, 17 Oct 2017, Paul E. McKenney wrote: > > > > > b. Compilers are permitted to use the "as-if" rule. > > > > > That is, a compiler can emit whatever code it likes, > > > > > as long as the results appear just as if the compiler > > > > > had followed all the relevant rules. To see this, > > > > > compiler with a high level of optimization and run > > > > > the debugger on the resulting binary. > > > > > > > > You might omit the last sentence. Furthermore, if the accesses don't > > > > use READ_ONCE/WRITE_ONCE then the code might not get the same result as > > > > if it had executed in order (even for a single variable!), and if you > > > > do use READ_ONCE/WRITE_ONCE then the compiler can't emit whatever code > > > > it likes. > > > > > > Ah, I omitted an important qualifier: > > > > > > b. Compilers are permitted to use the "as-if" rule. That is, > > > a compiler can emit whatever code it likes, as long as > > > the results of a single-threaded execution appear just > > > as if the compiler had followed all the relevant rules. > > > To see this, compile with a high level of optimization > > > and run the debugger on the resulting binary. > > > > That's okay for the single-CPU case. I don't think it covers the > > multiple-CPU single-variable case correctly, though. If you don't use > > READ_ONCE or WRITE_ONCE, isn't the compiler allowed to tear the loads > > and stores? And won't that potentially cause the end result to be > > different from what you would get if the code had appeared to execute > > in order? > > Ah, good point, I need yet another qualifier. How about the following? > > b. Compilers are permitted to use the "as-if" rule. That is, > a compiler can emit whatever code it likes for normal > accesses, as long as the results of a single-threaded > execution appear just as if the compiler had followed > all the relevant rules. To see this, compile with a > high level of optimization and run the debugger on the > resulting binary. > > I added "for normal accesses", which excludes READ_ONCE(), WRITE_ONCE(), > and atomics. This, in conjunction with the previously added > "single-threaded execution" means that yes, the compiler is permitted > to tear normal loads and stores. The reason is that a single-threaded > run could not tell the difference. Interrupt handlers or multiple > threads are required to detect load/store tearing. > > So, what am I still missing? ;-)
Well, you could explicitly mention that in the multi-thread case, this means all accesses to the shared variable had better use READ_ONCE() or WRITE_ONCE(). Alan
