Thread safe memory allocations?

We're using S5D9/D5 devices with SSP 1.60 and e2studio 7.3.0 and our project uses ThreadX.

It seems standard malloc/free routines are not thread safe and when called from multiple threads, heap is corrupted sooner or later. I tried to define __malloc_lock() and __malloc_unlock() routines to disable/enable interrupts just for the sake of test and problems disappeared. However, I'm not sure if it is sufficient and also disabling interrups is an overkill (I'd use mutex if it is a right way). I tried to search docs and found virtually nothing regarding this subject which probably means I'm missing something because it is really important thing.


- what is correct and supported way to handle it?

- can you point me to the right documentation?

- should we use a big ThreadX byte pool instead of standard heap?

- also, why SSP doesn't handle it internally? Or does it?



  • In reply to Renesas Karol:

    > All memory needed is allocated in the call to p_api->open

    Unfortunately, it isn't true. Today I added one more crypto instance and opened it as all others. It passed so I expected pool has necessary size. But when I called RSA sign later, it locked up waiting for pool memory. It was because RSA sign internally opened a hash instance which wasn't opened during original open and there wasn't enough pool for it.

    Oh well. I increased pool size and it works. However, it really isn't a good design. I'm affraid crypto pool has to be substantially oversized to handle all possible scenarios which is a waste of memory.
  • In reply to Michal:

    Hi Michal,

    Just wanted to follow up if you have been able to find solutions to your issue you discussed on this?

    RenesasRulz Forum Moderator