Single thread mode

[janjongboom]

Description

• Type: Enhancement

Enhancement

Reason to enhance or problem with existing solution

Mbed RTOS has a significant RAM overhead, even when non of the RTOS features are used. A K64F running mbed-os-example-blinky uses 6.3K more static RAM, even though it does not use any of the RTOS features. I suspect this memory goes into setting up all the RTOS contexts. What I'd like to see is some configuration option - not enabled by default - which still keeps the RTOS and features such as Semaphores, but without the RAM overhead. We could call it single thread mode. In addition, we could offer to enable newlib-nano / the ARMCC equivalent for these devices, shrinking memory usage even further.

This would make it easier to run Mbed OS on smaller targets like the DISCO-LRWAN1 which has 20K SRAM, and uses 19K of this when you have the LoRaWAN stack loaded; or even the xDot which has 32K SRAM. Often you want to squeeze as much out of these MCUs as possible, and switching to a single thread model is not such a bad idea if that means you can save 10K of RAM.

Here are some numbers (mbed-os-example-blinky on K64F with printf used, running a develop profile):

Configuration	Static RAM
With RTOS	12264
Without RTOS	5876
Without RTOS + newlib-nano	3276

Suggested enhancement

Introduce a single thread mode. All RTOS functions (except Thread?) should still be available, so this will work with LwIP and the Ethernet interfaces where RTOS functions are used for synchronisation. But memory usage should be similar to running without the RTOS.

Pros

More space on device, without having to rewrite some code because all the RTOS / synchronisation features are lost. F.e. Semaphore is very useful for switching between ISR and main thread, but is no longer available when removing the RTOS right now. Also a good way to show OEMs how to shrink down their application, and gives us a supported path for smaller MCUs.

Cons

Could maybe lead to people writing non-thread safe drivers.

/cc @geky @marcuschangarm @deepikabhavnani @ithinuel

[pan-]

It is already possible to disable the RTOS (see rtos/mbed_lib.json) however it removes access to the threading primitives (mutex, semaphore, etc...). Fortunately the event-queue library can be used without RTOS: The system goes to sleep when there is no events to process and it is possible to post events from ISR to process them in the event queue context (technically all of this happen in handler mode).

AFAIK, as RTX is right now, single thread mode would not improve memory requirements because memory needs to be allocated for the main thread stack; RTX cannot share the IRQ stack (handler mode) with the main thread stack (thread mode) as a consequence memory requirements would remain identical.

It would be nice to be able to select newlib nano out of the box however impact of this change is wider than threading issues as it touch on standard library compliance. Selection of this implementation should be a deliberate choice of the user; for now, users can select newlib-nano if they provide their own toolchain profile.

[geky]

Wouldn't a true single threaded mode drop RTX completely? That would result in the most code + RAM savings.

I think if anything this would actually encourage thread-safe drivers, since adding synchronization primitives (ie mutex, semaphore) no longer binds your library to the rtos being present.

[ithinuel]

Semaphore is very useful for switching between ISR and main thread, but is no longer available when removing the RTOS right now

Actually returning from interrupt always returns to thread you want as there's only one.

However to have a nice single thread environment, most API would have to be updated to provide non blocking calls to avoid stalling in the eventloop.
Maybe not with callbacks/interrupts but at least returning if result is ready or not.
And in such case

Could maybe lead to people writing non-thread safe drivers.

all driver with an "async" API should stay safe between the action request and its actual completion.

Semaphores/Mutexes are still required to manage resources if user implements future/Promise/event queue like api. The main difference is that their implementation would be much simpler.