On Sat, 2 Jan 2021 19:52:50 -0800, Paul E. McKenney wrote: > On Sun, Jan 03, 2021 at 12:04:24AM +0200, Daniel Nitzan wrote: >> In 15.5.1 (Alpha) - In regard to the following statement: "Yes, this >> does mean that Alpha can in effect fetch the data pointed to before it >> fetches the pointer itself, strange but true." >> I'd appreciate it if someone could clarify what this means. I don't >> understand this statement in light of the actual data-dependent >> reordering presented in this section, i.e. the pointer itself is >> fetched, points to the correct location in memory, but the data is >> stale. > > Yes, your last statement is equivalent. Either way, the reading CPU sees > the new value of the pointer and the old value of the pointed-to data. > You can look at it either as counter-intuitive reordering (as I did) > or as counter-intuitive stale data (as you did). > > The key point is that these values are not in a single location, but > are instead replicated across the CPUs' caches. Stores are therefore > not atomic unless the hardware goes to a lot of trouble to make them > appear to be atomic. Hi Paul, Off topic, but smp_read_barrier_depends() as a kernel API has been removed since Linux v5.9 [1]. Now READ_ONCE() for Alpha uses mb() [2]. You might want to reflect these changes in perfbook before the release of the Second Edition. [1]: merge commit https://git.kernel.org/linus/145ff1ec090d ("Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux") [2]: commit https://git.kernel.org/linus/d64628588515 ("alpha: Override READ_ONCE() with barriered implementation") Thanks, Akira > > Thanx, Paul >