This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ARMv8 memory ordering

In the ARM Architecture Reference Manual issue D.a (ARM DDI 0487D.a) section K11.3.1 "Acquiring a lock" has the following example code:

AArch32 
Px
        PLDW[R1]                     ; preload into cache in unique state
Loop
        LDAEX R5, [R1]               ; read lock with acquire
        CMP R5, #0                   ; check if 0
        STREXEQ R5, R0, [R1]         ; attempt to store new value
        CMPEQ R5, #0                 ; test if store suceeded
        BNE Loop                     ; retry if not

        ; loads and stores in the critical region can now be performed

My question is I can not find documentation  in Chapter E2 "The AArch32 Application Level Memory Model" that would prevent a speculative store after the BNE from being accelerated before the STREXEQ causing the store to be observed by another observer before the lock is acquired.

Version A.j of the manual contained the following statement: "Speculative writes by an observer cannot be observed by another observer." Which would preclude this from happening but I can find no equivalent statement in the latest manual.

Parents
  • I did, they sent me to this forum. This is somewhat understandable because the ARM architecture is what defines the memory model not the SoC.
    I can not speak to the system design, I write a general purpose OS that gets used on multiple systems (most of which I never see). Safety critical systems normally have redundancy using dissimilar hardware but this does not mean the software can be developed assuming a bug will be caught by some other means.

    I realize the ARM architecture is not developed to any safety critical  standard so there is no guarantee the processor will work as documented but that is all I have to go on and at this point in time my interpretation of the memory model section is the code in K11.3.1 "Acquiring a lock" is incorrect. Based on things I have read (including the papers refereed to above) I do not actually believe this section is incorrect and I was hoping someone on this from this forum would be able to point to the ARM documentation that I am missing.

Reply
  • I did, they sent me to this forum. This is somewhat understandable because the ARM architecture is what defines the memory model not the SoC.
    I can not speak to the system design, I write a general purpose OS that gets used on multiple systems (most of which I never see). Safety critical systems normally have redundancy using dissimilar hardware but this does not mean the software can be developed assuming a bug will be caught by some other means.

    I realize the ARM architecture is not developed to any safety critical  standard so there is no guarantee the processor will work as documented but that is all I have to go on and at this point in time my interpretation of the memory model section is the code in K11.3.1 "Acquiring a lock" is incorrect. Based on things I have read (including the papers refereed to above) I do not actually believe this section is incorrect and I was hoping someone on this from this forum would be able to point to the ARM documentation that I am missing.

Children
No data