Question: is the memory allocator interrupt safe?

[dpgeorge]

I'm wondering if memory allocation is safe with respect to interrupts. I see in the MicroBitRadio class that it executes new FrameBuffer() within the RADIO_IRQHandler function. What happens if the radio interrupt fires while a new/del is ongoing?

[finneyj]

Good question. The MicroBitHeapAllocator functions are safe as it briefly disabled interrupts in the critical section of code, but the mbed ones are not... At least that's what is documented on mbed.org (I haven't tested personally). Given that it is now possible to create components without using MicroBitHeapAllocator, we should make sure it is safe for all sane build configurations...

I think two possibilities here:

• Even if MicroBitHeapAllocator is not initialized, the indirection wrapper is still there in MicroBitHeapAllocator.h. So we could trivially wrap the native malloc/free new/delete calls to disable interrupts here too. This would guarantee equivalent behaviour for all modules, at the expense of losing a little timing accuracy.
• We rework the components with any interrupt context code to not rely on this feature - most likely pre-allocation of memory in constructors / accessor methods etc. e.g. in the RADIO case we would pre-allocate in the constructor and recv() methods etc.

Thoughts?

I think I slightly prefer the former, as it keeps things consistent and safe for all current and future code, hasn't caused any issues when running under MicroBitHeapAllocator...

[dpgeorge]

In general interrupts should be fast, and interrupts should not be disabled for a long period of time. So I'd suggest making sure that irq handlers don't allocate on the heap.

[finneyj]

Indeed. These are indeed very fine general principles, of course @dpgeorge.

What happens when you logically follow this approach is that each of those modules then start to use some form off memory pooling (as above), which often increases RAM footprint a bit... so then someone looks to share those pools for efficiency... then says "why not make it transparent?" then you end up with some sort of interrupt safe heap allocator. :-) This was actually one of the reasons the MicroBitHeapAllocator class came into being (the other reasons including the ability to have a split heap regions).

I also wonder a bit about the complexity of having different semantics... i.e. Q: "is it safe to allocate memory in interrupts on microbit?" A:"Well, it depends..."

Perhaps we need some more evidence here. Knowing how long a typical allocation and free operation actually takes would let us make a more informed decision?

[dpgeorge]

If the radio interrupt is the only irq handler in the whole system that allocates heap memory, then I'd say change it so it is allocated outside the irq. Otherwise I guess the principles of the DAL are that you can allocate during an interrupt and users should understand the benefits/consequences of that.

[finneyj]

Yes, i think that is indeed at the heart of the issue... drawing the line at the correct place between performance and simplicity.

There are a couple of places where this could happen to my knowledge, queuing an event raised in interrupt context being the most common. Also one or two BLE functions (lots of BLE callbacks in the Nordic stack, all of which run in IRQ context).

I suspect that the RADIO component is the only one that would affect micropython though.