<div dir="ltr">Thanks for your reply! I should have read more carefully... Besides, do you know where can I find the specific rules of LKMM? Now it seems that two irrelevant READ_ONCE()s can execute out of order, what about two WRITE_ONCE()? or a READ_ONCE() followed by a WRITE_ONCE()? etc... Intel gave several examples in it's manual (Volume 3, 8.2.3). Does LKMM provide similar examples?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">FMDF <<a href="mailto:fmdefrancesco@gmail.com">fmdefrancesco@gmail.com</a>> 于2021年10月25日周一 下午7:33写道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Oct 25, 2021 at 10:33 AM Zhang Zeren <<a href="mailto:zhangzr23@gmail.com" target="_blank">zhangzr23@gmail.com</a>> wrote:<br>
><br>
> Hi, I read an example in the Documentation/memory-barriers.txt, which says<br>
>><br>
>>  (*) On any given CPU, dependent memory accesses will be issued in order, with<br>
>>      respect to itself.  This means that for:<br>
<br>
"dependent" _is_ the key to understanding this topic. As Valentin<br>
Vidić wrote, your loads are _not_ dependent and / or related in any<br>
way.<br>
<br>
> As far as  I understand it, linux kernel memory model (LKMM) guarantee two read operations<br>
> execute in order. And if the CPU architecture offer an looser memory ordering (like Alpha), then<br>
> the compiler must help to add a memory barrier after the load instruction to fufill the LKMM's<br>
> standard.<br>
<br>
No, adding a memory barrier is not a compiler job, instead it is up to<br>
the kernel code.<br>
For instance, please take a look at the implementation of<br>
__READ_ONCE() for Alpha in arch/alpha/include/asm/rwonce.h (note that<br>
__READ_ONCE() is used by READ_ONCE()).<br>
<br>
Regards,<br>
<br>
Fabio M. De Francesco<br>
</blockquote></div>