Racing adventure in OS

[Lyu.1]

Hi,Master:

Question 1:

As shown in the figure below, why does the api read this variable with critical protection?

Question 2:

Suppose two tasks have write operations to shared variables. For example:

int var;
void task1(void)
{
    OS_ENTER_CRITICAL();
    var = 1;
    OS_EXIT_CRITICAL();
}
 
void task2(void)
{
    OS_ENTER_CRITICAL();
    var = 2;
    OS_EXIT_CRITICAL();
}

In the OS source code, you can see that a critical section must be added to the shared variable write operation. There is no read-modify-write, and it should not cause a race condition. Why do you need to add a critical section?

Question 3:

If the compiler has done level optimization, there may be a write cache for variable writes. In this case, should the DSB data synchronization barrier be increased after the variable is written in the critical section? I don’t know when to use DSB, ISB, etc. instructions

Thank you very much.

[TDK · Accepted solution]

1) It is unnecessary as reading int32_t is atomic. You would need to ask the author why it's there.

2) You don't need it here either. However, two tasks blindly overwriting the same variable feels like bad design. Perhaps if they both set it to the same value it may make sense.

3) If it's in cpu cache, the next thread will use the value in cache rather than in memory and DSB is not needed. You would need DSB if there is a hardware reason the value needs to be in memory, which is rarely (but occasionally) the case.

[Lyu.1]

ok, Thank you very much for your answers​

[Tesla DeLorean]

Lacking additional context I'd assume this is coded to handle a 16-bit (or 8-bit) MCU​

[Guillaume K]

I've never seen OS_ENTER_CRITICAL() / OS_EXIT_CRITICAL().

By searching on Internet I see these functions seem related to uCOS and not related to STM32 specifically.