On Thu, Nov 7, 2019 at 10:29 AM Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> On Thu, Nov 7, 2019 at 10:22 AM Alexander Potapenko <glider@xxxxxxxxxx> wrote:
> > On Thu, Nov 7, 2019 at 10:04 AM Arnd Bergmann <arnd@xxxxxxxx> wrote:
> > > On Thu, Nov 7, 2019 at 7:08 AM Sergey Senozhatsky
> > > <sergey.senozhatsky.work@xxxxxxxxx> wrote:
> > > >
> > > > Yeah, 'volatile' in this case will do what it sort of meant to do - prevent
> > > > compiler optimizations. So, like you said, it's not a synchronization issue
> > > > and we don't 'volatile' data structures.
> > >
> > > The normal way to do a volatile access would be
> > > READ_ONCE()/WRITE_ONCE(), but that seems stronger than
> > > the barrier() here. I'd just stick to adding a barrier.
> > I actually like the READ_ONCE idea more, as READ_ONCE is really a
> > documented way to prevent the compiler from merging reads, which is
> > what we want here.
>
> Fair enough.
>
> > I also thought that the original barrier() statement was just a
> > compiler barrier, which didn't introduce any additional CPU
> > instructions.
> > Turns out I was wrong, and barrier() also serves as a memory barrier.
>
> The definition of barrier is
>
> #define barrier() __asm__ __volatile__("": : :"memory")
>
> which is no actual barrier instruction but is a full barrier to the compiler.
And you're right again, shame on me and my reading skills.
> Only for the Intel ecc compiler it is defined as an intrinsic that I don't
> know.
> Arnd
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
