pvPortMalloc() and how "ESP-IDF FreeRTOS" solve the thread safe malloc() problem.

[Gfast2]

Hi ESP-IDF,

Big thanks for your support till now! You are awesome, as a jump-starter, I've learned so much from you guys. You are awesome!

Since I only found this post about pvPortMalloc(). and I do know that "ESP-IDF FreeRTOS" is somehow very special. I'd like to know:

How ESP-IDF FreeRTOS protect two cores try to allocate memory from the same memory address at the same time. I've learned so much from the symmetric multiprocessing (SMP) FreeRTOS Architecture from you, But still not sure at this point. (Language Wall, not enough background know-how )

Cheers

Gfast2

[kolban]

In multi-threaded programming we have the notion of a "mutex". Think of this a gate that ensures that only one task at a time can work in a critical area. Contrast this with visit a gas station and wanting to use the bathroom. In order to use the bathroom, you have to ask the clerk for the key. While you are using the bathroom, you have the key and no-one else can use it. When you leave, you return the key and anyone waiting can then use it themselves.

Now back in ESP32 land, I'm assuming that there are data structures that represent the used and available memory in the heap. Obviously, two tasks can't allocate heap memory at *exactly* the same time ... so it would be my guess that a mutex would be used. The task comes along, grabs the mutex, asks for memory, gets the memory, releases the mutex. Since only one task can ever take the mutex at one time, we have "serialization" of this "critical section".

[Gfast2]

In multi-threaded programming we have the notion of a "mutex". Think of this a gate that ensures that only one task at a time can work in a critical area. Contrast this with visit a gas station and wanting to use the bathroom. In order to use the bathroom, you have to ask the clerk for the key. While you are using the bathroom, you have the key and no-one else can use it. When you leave, you return the key and anyone waiting can then use it themselves.

Now back in ESP32 land, I'm assuming that there are data structures that represent the used and available memory in the heap. Obviously, two tasks can't allocate heap memory at *exactly* the same time ... so it would be my guess that a mutex would be used. The task comes along, grabs the mutex, asks for memory, gets the memory, releases the mutex. Since only one task can ever take the mutex at one time, we have "serialization" of this "critical section".

Hi Kolban,

I can even tell you, your example for mutex as the key for gas station bathroom is from your book! Yesterday or so I've read that part!

Back to my question. I did some how understood the "ESP-IDF FreeRTOS" deploy mutex for its cretical section handling. But I do not read any much concret descriptions that address my question above. My colleage told me, many years before our company choosed a propertary RTOS, which later on is figured out not have such a mechanisum. Many hundurds of developing hours are just investigated into some places without a bright future...

Cheers

Su

[ESP_Sprite]

if you understand mutexes, the malloc() issue becomes pretty simple. When a thread tries to malloc() something, the memory allocation code first grabs the mutex, then finds a chunk of suitable memory to use, marks this memory as used and updates all memory allocation internal data to reflect this, then returns the mutex. Because the memory allocation data is consistent before and after the mutex is held, and another thread cannot malloc during the modification of the internal memory allocator data (because it can't get the mutex), consistency is guaranteed.

[Gfast2]

if you understand mutexes, the malloc() issue becomes pretty simple. When a thread tries to malloc() something, the memory allocation code first grabs the mutex, then finds a chunk of suitable memory to use, marks this memory as used and updates all memory allocation internal data to reflect this, then returns the mutex. Because the memory allocation data is consistent before and after the mutex is held, and another thread cannot malloc during the modification of the internal memory allocator data (because it can't get the mutex), consistency is guaranteed.

Hi ESP_Sprite,

Thanks for your official answer. Because in ESP-IDF doc about ESP-IDF FreeRTOS's Critical Sections & Disabling Interrupts I only get very general answer for instructions like this one, so I'd prefer to ask someone to make sure this do exist. But thanks for kolban's good example, too.

I'm very happy about your answer, this gives me more confidence for the upcomming developments.

Cheers

Gfast2

[ESP_Sprite]

In general, the thing you're looking for is called 'thread-safe'; if something is thread-safe, it essentially means that whoever wrote it took care to accommodate for the possibility of multiple threads (possibly running on different cores) running the same code path at the same time, and that the code will still work as expected when this happens. In general, you can assume all documented functions in esp-idf are threadsafe, unless it's explicitly stated they are not. (If you manage to find a non-thread-safe function and the docs don't mention this, this is a bug and in that case we'd appreciate a bug report on the Github issue tracker.)

[Gfast2]

In general, the thing you're looking for is called 'thread-safe'; if something is thread-safe, it essentially means that whoever wrote it took care to accommodate for the possibility of multiple threads (possibly running on different cores) running the same code path at the same time, and that the code will still work as expected when this happens. In general, you can assume all documented functions in esp-idf are threadsafe, unless it's explicitly stated they are not. (If you manage to find a non-thread-safe function and the docs don't mention this, this is a bug and in that case we'd appreciate a bug report on the Github issue tracker.)

Hi ESP_Sprite,

cool, nice to know the scientific name of it. To tell the truth, I do understand what threadsave means. But I didn't realize that malloc() can be in some platform not threadsave. Yeh, the real world is like a jungle!

I'm looking up forward. If I did found some issue, I will post it on here or Issue section in Github repo.

Cheers

Gfast2