understanding the logics behind rtos:: vs mbed::

[jerabaul29]

I am playing around on a few recipes, and one thing that confuses me is when I should use some rtos:: vs some mbed:: namespaces when using functions / classes from Mbed-OS. For example:

https://github.com/jerabaul29/Artemis_MbedOS_recipes/blob/dd4c9fcbfec38fb09a3675a494fb442119336247/recipes/recipe_reed/test_reed_switch_3pins/test_reed_switch_3pins.ino#L13

rtos::Mutex use_reed_values;

but:

https://github.com/jerabaul29/Artemis_MbedOS_recipes/blob/dd4c9fcbfec38fb09a3675a494fb442119336247/recipes/recipe_reed/test_reed_switch_3pins/test_reed_switch_3pins.ino#L29

      mbed::ScopedLock<rtos::Mutex> lock_reed{use_reed_values};

• am I doing something wrong (cannot be that wrong, it compiles ^^), or more complicated than it needs?
• what is the logics behind which prefix to use / am I / what am I missing? :)
• is it possible that there is something in how the core is set up that actually makes this more complicated than it needs? Should / could all of rtos:: simply be mbed:: instead?

[jerabaul29]

I wonder if this is related to "what is being provided by MbedOS natively, and how" compared with "what is being re-implemented by hand". @adamgarbo I wonder if this also plays a role in how the watchdog (can) get MbedOS "API compliant" at some point :) .

Do you have some explanations about how this works @Wenn0101 @oclyke ? I wonder if having a small note / technical document somewhere about what comes from MbedOS and how, and where some bridging or coding "by hand" is needed, would be useful to people (like me) who try to understand the relation between this core and MbedOS.

[oclyke]

rtos:: is a namespace used within mbed. sometimes we have had clashes with mbed namespace items so we had to hide these behind mbed::

[oclyke]

closing in favor of this discussion #352