LDREX/STREX on the M3,M4,M7

So imagine that I have a RTOS with fixed time sliced scheduling

Task 1 with medium priority goes to get a MutexAddress1 but the LDREX shows the task is not in use, but task gets removed from processor before the SDREX. 

Task 2 gets processor and gets MutexAddress1 and before it is done with mutex is bumped from processor.

Task 3 goes to get MutexAddress2 and does the LDREX and the mutex is free, but gets bumped from processor before STREX.

Task 1 gets put back on processor and does the STREX, which should fail. However since the address resolution on the LDREX/STREX is the entire memory it thinks the LDREX from Task 3 (MutexAddress2) is the same as the STREX for MutexAddress1.  So now Task 1 thinks it got the Mutex and so does Task 2. 

Yes it takes a complex example to show the case where it fails and the likelihood this happens in the real world is very low but it is not zero. 

To make a simple test case you could do this:

LDREX mutexAddress1

LDREX mutexAddress2

STREX mutexAddress1 --- If this passes the system is broken. 

According to what I have read in the following documents from ARM the above simple case will break on the M3,M4, and M7 cores. 

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka16180.html

The only way I can see to get around this is that every interrupt/exception (ie task switch) issue a CLREX such that if any exception that happens between the LDREX and STREX the STREX will fail. 

So imagine that I have a RTOS with fixed time sliced scheduling

Task 1 with medium priority goes to get a MutexAddress1 but the LDREX shows the task is not in use, but task gets removed from processor before the SDREX. 

Task 2 gets processor and gets MutexAddress1 and before it is done with mutex is bumped from processor.

Task 3 goes to get MutexAddress2 and does the LDREX and the mutex is free, but gets bumped from processor before STREX.

Task 1 gets put back on processor and does the STREX, which should fail. However since the address resolution on the LDREX/STREX is the entire memory it thinks the LDREX from Task 3 (MutexAddress2) is the same as the STREX for MutexAddress1.  So now Task 1 thinks it got the Mutex and so does Task 2. 

Yes it takes a complex example to show the case where it fails and the likelihood this happens in the real world is very low but it is not zero. 

To make a simple test case you could do this:

LDREX mutexAddress1

LDREX mutexAddress2

STREX mutexAddress1 --- If this passes the system is broken. 

According to what I have read in the following documents from ARM the above simple case will break on the M3,M4, and M7 cores. 

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka16180.html

The only way I can see to get around this is that every interrupt/exception (ie task switch) issue a CLREX such that if any exception that happens between the LDREX and STREX the STREX will fail. 

Hi there,

In Cortex-M, exclusive state automatically get cleared in exception events (this is different from Cortex-A in Armv7-A, but I think Armv8-A clear exclusive state automatically as well).

https://developer.arm.com/docs/ddi0403/e/armv7-m-architecture-reference-manual

Section A3.4.4 Context switch support

"It is necessary to ensure that the local monitor is in the Open Access state after a context switch. In ARMv7-M, the local monitor is changed to Open Access automatically as part of an exception entry or exit sequence. The local monitor can also be forced to the Open Access state by a CLREX instruction."

Hope this cleared your concern.

regards,

Joseph

Wonderful!  Then it make a lot more sense to use.... 

I figured that Arm Engineers would have thought through this, but could not find enough details online to figure it out. 

Thanks

Trampas

You're welcome :-)