About the Tx_CMSIS_Wrapper example

[SMacl.1]

I am new to STM32, been looking at it just a week, have an L4R9 Disco board. I am familiar with the CMSIS RTOS2 api, and have used RTX previously. Was interested to see the Tx_CMSIS_Wrapper example, as it shows how an RTOS2 facade is added to Azure RTOS ThreadX.

What I don't get is the apparent need for a Mutex/Semaphore in the example. The two threads are toggling separate LEDs, and share no data (ram nor peripheral registers). Yes, they do both call printf, 3 times, but ironically 2 of the 3 calls aren't in the critical region anyway.

Am I missing something here, or is there a fundamental misunderstanding of concurrent programming on the part of that code's author? The README within the project states that (paraphrasing) "because both threads call Led_Toggle, this is considered a critical region... ". Shared DATA needs sequential access, but two threads that happen to be sharing CODE does not.

[Piranha]

https://github.com/STMicroelectronics/x-cube-azrtos-l4/blob/main/Projects/STM32L4R9I-Discovery/Applications/ThreadX/Tx_CMSIS_Wrapper/Src/app_tx_cmsisrtos.c

That is an example of how to use the API, not how to blink LEDs. Ironically the printf() calls should be mutually exclusive, but are not... And at least for Newlib runtime library most likely it's broken anyway:

https://community.st.com/s/question/0D53W00001KRfkeSAD/is-stm32cubeide-newlib-with-freertos-now-really-thread-safe

[SMacl.1]

Yes, but doesn't the code as written lead an RTOS newbie into believing "I have two threads that syntactically call the same function, I must therefore need a mutex" ? Maybe I am overthinking it.