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.
Thanks for the links, they provided some interesting reading material, unfortunately product I work on is for aircraft and if incorrect people could die so I really need some formal ARM provided documentation that backs up the claims made by these papers.
You should contact the manufacture of the SoC instead of this forum.Anyway, you would not rely in a safety critical system on a single SoC, would you?
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.
Oh. Would it not be proper to open a support case with Arm? Or, on the side, to check the object code the modern c++ compilers generate for locking? If licensing isn't an issue, one can also check the source or the object code of current mainstream OSes.
One can also implement locking without relying on instructions with acquire/release semantics - by adopting the no-ordering ldrex/strex pair and by placing explicit barriers (dmb) at appropriate locations in the lock/unlock routines. This should help the project move forward, while awaiting a reply from Arm.
Regardless of the presence or absence of any documentation, propagating speculative writes lends them a sort of certainty to which they are not entitled; not until it can be known that they can be committed.