We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
semaphore_take: mov w2, #1 // LOCK value dmb sy // ensure all observers observe data before aquire is attempted ldaxr w1, [x0] // attempt to read and aquire lock cbnz w1, semaphore_take // lock is not zero so loop and try and aquire again stxr w3, w2, [x0] // attempt to store LOCK value cbnz w3, semaphore_take // retry if store failed dmb sy // ensures that all subsequent accesses are observed after gaining of the lock is observed
The above semaphore code worked flawlessly until the moment I added FIQ code.
Now the semaphore leaks thru critical sections even though the FIQ does not come anywhere near the semaphore.
Is there something I need to know about FIQ and LDREX/STREX functions?
I mostly agree, except for the last sentence, which depends on which system it runs on.
It is implementation defined if CLREX has an effect on the global monitor:
"When the global monitor is in the Exclusive Access state, it is IMPLEMENTATION DEFINED whether a CLREX
instruction causes the global monitor to transition from Exclusive Access to Open Access state."
ok, thanks. I am thinking, of the implication of this ... can't find any.In fact, the problem the OP saw should not be solved by using a CLREX in the FIQ code. So maybe the problem LdB has lies somewhere else.