Number of mbedOS mutexes exceeds maximum allowed when compiling with ARMCC

[alekshex]

Description

• Type: Bug
• Related issue:
  1d4cd0a
  Relates to this definition
• Priority: Blocker

---

Bug

Target
K64F

Toolchain:
ARM

Toolchain version:

mbed-cli version:
(mbed --version)

meed-os sha:
latest tag

DAPLink version:

Expected behavior
No assertions occurs in the system

Actual behavior
os is out of available mutex resources, while application uses only 1.
all the rest seem to be consumed by os itself.

Steps to reproduce
Use of file system and serial port communication leads to 'out of mutex resources' in mbedOS
when bin is compiled with ARMCC toolchain.
(please see here:
1d4cd0a)
Current default number of allowed mutex resources (8) is not enough.

Also it is unclear how much mutexes are allowed to be used by user application
and how many are consumed by the os itself.

[alekshex]

@shelib01 witnessed this issue in KCM module
cc: @liatvindzberg @yogpan01 @JanneKiiskila

[0xc0170]

cc @bulislaw

[JanneKiiskila]

Q: Why aren't the mutexes dynamic? If they have to be hard-coded, should it not be controllable via an mbed_app.json parameter? (Although in this particular case - this is likely about something else).

[bulislaw]

Dynamic memory it disabled for RTX, therefore, generally speaking, there are no RTX object available to use (without supplying external storage memory). ARMC is exception from the rule as the toolchain library requires some number of dynamic mutexes, but by using this pool you are removing them from the system, possibly leading to a crash.

Why there's no dynamic memory for RTX objects in mbed OS is a very good question. The only way that could be implemented is by having a second HEAP, private to RTX, considering limited resources available for most platforms, we decided no to do that and instead require people that don't want to or can't use C++ RTOS API to provide their own memory for RTX objects. Unfortunately it's not possible to use system's heap for RTX or RTX's heap for system heap. We've investigated it and discussed the problem with CMSIS/RTX team, deciding that people that can't use C++ RTOS APIs would need to supply memory for RTX.

[sg-]

@avolinski If you need more help please provide a snippet showing how this is being used and failing. With that, repoen the issue.

[TaniaMirzin]

@sg-
@avolinski
@shelib01
Hi ,
Alex, please reopen this issue.
Sam, please our application that reproduce this issue - https://github.com/ARMmbed/mbed-mutex-restore.
This application works only with mbed-os,sd-driver, pal and esfs.(wihout factory-configurator-clinet and kcm).
I added comments for each operation that increase num of mutex.
This application fails on esfs_close() operation.

[bulislaw]

No access to your app.

[TaniaMirzin]

@bulislaw
Please check now, i added mbed-os-coresw group to collaborators list

[bulislaw]

I can confirm, all the mutexes are created by the toolchain. As a workaround you can bump the number of available mutexes to 9. I'll think about more sustainable solution as we keep finding usecases that require more and more mutexes.

diff --git a/rtos/rtx5/mbed_rtx_conf.h b/rtos/rtx5/mbed_rtx_conf.h
index f54770072..e1a4b74a6 100644
--- a/rtos/rtx5/mbed_rtx_conf.h
+++ b/rtos/rtx5/mbed_rtx_conf.h
@@ -38,7 +38,7 @@

 #if defined(__CC_ARM)
 #define OS_MUTEX_OBJ_MEM            1
-#define OS_MUTEX_NUM                8
+#define OS_MUTEX_NUM                9
 #endif

 #if !defined(OS_STACK_WATERMARK) && (defined(MBED_STACK_STATS_ENABLED) && MBED_STACK_STATS_ENABLED)

[JanneKiiskila]

Please label this as OSCA! @sg- @0xc0170 @bulislaw

[bulislaw]

Label doesn't exist, I don't have powers to create a new one. @sg-