• State Accepted Answer
  • Locked Locked
  • Replies 9 replies
  • Subscribers 352 subscribers
  • Views 16910 views
  • Users 0 members are here
2025 survey

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.

Options
Related
How was your experience today?
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

LDREX/STREX on the M3,M4,M7

Trampas

Doing some research of the LDREX and STREX it appears that the exclusivity address range for these instructions on the M3,M4,M7 is the entire memory space. Hence you can only use the LDREX/STREX with one address.   Does this not limit you to one Mutex (or at most 32 if you can bit map them?). 

Thus it does not seem to be a very practical solution for an RTOS, or am I missing something? 

Parents
  • 0
    The chance that an interrupt/exception happens between the LDREX/STREX will increase dramatically while you are the use of it for a mutex with a spin wait on a lock. Especially the code can be spinning on round ~10 instructions and if their is one CMP among LDREX and STREX.
Reply
  • 0
    The chance that an interrupt/exception happens between the LDREX/STREX will increase dramatically while you are the use of it for a mutex with a spin wait on a lock. Especially the code can be spinning on round ~10 instructions and if their is one CMP among LDREX and STREX.
Children
  • 0 Arm Employee Badge in reply to Edwin Knox

    Instead of keep running in the spin lock loop, often an semaphore API could send a request to OS to context switch to other tasks if the spin lock cannot proceed, the OS could put this task in wait queue and get back to this spin lock later when another task release the semaphore (this require the semaphore release API to inform OS kernel of the change).