On Fri, Jul 21, 2017 at 08:24:40AM +0800, Boqun Feng wrote: > On Thu, Jul 20, 2017 at 04:07:14PM -0700, Paul E. McKenney wrote: > [...] > > > > > > So if I respin the patch with the extern, would you still feel reluctant? > > > > Yes, because I am not seeing how this change helps. What is this telling > > the reader that the original did not, and how does it help the reader > > generate good concurrent code? > > One thing I think we probably should do is to make READ_ONCE() semantics > more clear, i.e. call it out that in our conceptual model for kernel > programming we always rely on the compiler to be serious about the > return value of READ_ONCE(). I didn't find the comment before > READ_ONCE() or memory-barriers.txt talking about something similar. > > Or am I the only one having this kinda semantics guarantee in mind? That sounds like a good idea to me. The C++ standards committee might be reluctant to provide a good definition of "volatile", but we can at least provide a definition of our own. It should be possible to leverage the need for "volatile" to support MMIO accesses, as there is general agreement that this was and still is its main purpose. Given those guarantees, there is no reason we cannot apply them in other situations, for example, interacting with irq handlers and preventing inappropriate optimizations for concurrent code. Even better, with tests to find compiler bugs in this area! Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
