Re: Is Alpha non-other-multicopy atomic?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ignacio Encinas Rubio wrote:
> On 16/3/25 12:37, Akira Yokosawa wrote:
>> As is well known, Alpha is infamous of its lack of address-dependency
>> guarantees.  I don't see much point in discussing whether it is multicopy
>> atomic or not.
> 
> I agree this is not particularly important, I just found contradicting
> information and wanted to clarify/fix Table 15.5.
> 
>> If you have access to an Alpha machine with 3 or more CPUs,
>> you should be able to run this test with the help of klitmus7.
> 
> Thanks for the test. Sadly, I don't have access to an Alpha CPU (I was
> born after DEC was bought by Compaq)

That is what I had anticipated ...

> 
>> Finally, my mental model of other-multi-copy might be different from
>> those defined in papers you cited below. 
> 
> Might be, I have just realized mine is wrong. I have just run Listing 
> 15.16 (C-WRC...) in herd using the "linux" model to realize the exists
> clause can trigger. 
> 
> Note that it can do so while "RFE" imposes order for the "linux" model 
> (it is part of happens-before), so my original comment stating 
> 
>   non-mca == rfe does not impose order 
> 
> is wrong if Read[X = 0] (fr) -> Write[X = 1] does not mean that the read
> is ordered before the write. However, this doesn't seem to be the case
> for Alpha [3]
> 
>   Section 5.6.1.2: The ordering relation Before (<=) is acyclic
>   Section 5.6.1.4: If u and v are overlapping read/write accesses, at
>     least one of which is a write, then u and v must be comparable in 
>     the BEFORE (<=) ordering, that is, either u <= v or v <= u.
> 

The wording "If u and v are overlapping read/write accesses" sounds to
me like it has nothing to do with what perfbook calls "multicopy atomicity".
It is more related to the concept of perfbook's "single-copy atomicity" or
"coherency", isn't it?

Quite from Section 15.3.6:

  On cache-coherent platforms, all CPUs agree on the order of loads and
  stores to a given variable. Fortunately, when READ_ONCE() and WRITE_ONCE()
  are used, almost all platforms are cache-coherent, as indicated by the "SV"
  column of the cheat sheet shown in Table 15.3. Unfortunately, this property
  is so popular that it has been named multiple times, with "single-variable
  SC", "single-copy atomic" [SF95], and just plain "coherence" [AMP+11]
  having seen use.

Miss-orderings related to address-dependent loads on Alpha happen only
when two variables belong to two different cache banks as shown in
Figure 15.25.
They don't happen when u and v overlap (and share a cache line).

I'm suspecting that the meaning of "multicopy atomicity" in perfbook
(or LKMM), and/or my interpretation of it, might not be exactly the
same as what is widely accepted by computer industry people.

Are we on the same page now?

> It's still my opinion that Alpha is other-multi-copy atomic but I
> understand it is a bit pointless to discuss about this... Sorry, I
> couldn't resist.

No need to apologize.
Any feedback from a fresh minded reader is much appreciated!

        Thanks, Akira

> 
> Thanks
> 
> [3] https://download.majix.org/dec/alpha_arch_ref.pdf
> 
>





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux