Confusion of waste ram by TaskNotification array

Suppose a APP with ten task, one of these task need to use three notifications, others only need one at most.
so here app need to set configTASK_NOTIFICATION_ARRAY_ENTRIES to be 3,
then 9x10bytes have been dissipated.
what about situation of one of 50 tasks using three notifications only, can’t help but say it ,unaccepted waste ram.
Am I understand right? Is there any option to stop the waste?

Do you mean 3 single notifications (bits) or 3 notification values (with 32 bit per value) ?
However, it would make the implementation much more complicated and cause more overhead to have a dynamic notification array. So I think it’s like it is.
If you really have to fight for each byte of memory usage it could be a hint to refactor/redesign the application e.g. reducing the number of tasks. That would probably save a lot more memory than needed just for the notification array.

At this time there is only a single compile time constant that sets the number of indexes in the notification array - and that then applies to every created task. Maybe we could consider making this a per-task setting? Although the application writer would have to keep track of how many indexes in the array each task had, and it could only practically be done by dynamically allocating the notifications after the task was created. We would have to determine whether the use cases warranted that additional functionality though. Each notification consumes 5 bytes, and until V10.4.0 tasks managed with a single notification each, so I’m not sure how much RAM would be wasted for average applications. Systems with 50 tasks would be extremely rare, so not average, and probably only practical on platforms where multiples of 5 RAM bytes are going to be inconsequential compared to the amount of RAM used by 50 task stacks.

Thanks for your attention.
Well, I agree of fighting for each byte of memory usage is an important principle of MCU base app.
I remember that FreeRTOS’s list use xMINI_LIST_ITEM instead of xLIST_ITEM for saving about 12bytes.

excuse me ,I just put out my confusion ,can’t offer any solution.
now that as said Tasknotification has two obvious advantage compare to semaphore: fast and small footprint.
and it apply to every created task, I am afraid of that the highest number of notification used by any task could impact the total usage of ram.
for example,
app totally has 3 task running. one of them use 5 notification by set configTASK_NOTIFICATION_ARRAY_ENTRIES to be 5(it is possible,no one limits it just to be set 0 or 1), but left tasks were not use notification, but forced to waste 2x5x5bytes.

The important thing to remember is that using a single notification word still allows a task to act like it has 32 semaphores (one per bit of the notification word), so you only really need the additional array entries if using it as ‘mailbox’. One of the big reasons, as I understand it, that this feature was added is that the stream/message buffers use a simple notification event (not using a bit) and this interfered with other apps doing the same, so now those apps could just use a different index and continue. If they had actually been using a bit, my understanding is they would have continued to work.

As has been mentioned, making it a variable amount would likely actually cost MORE ram in most cases (or greatly complicate static creation) as the over head of a dynamic allocation is similar to several notification entries.

sorry for not reply,
Obviously,I mean 3 notification values.

OK,thank you for your guidence.Sir.
yes, I using it as ‘mailbox’ or a lightweight ‘queue’.
as stream/message buffers are new feature, I thought they were been used at multicore apps as the main target. Did I understand right?
so, I use queue at most situation when needed.excuse me ,I am not familiar with using them.

stream/message buffers aren’t ‘just’ for multicore, though they do have ways to be adapted to be used for such with a bit of special code. They are a lighter weight version of the queue with additional capabilities. Lighter weight in that they support just a single reader and a single writer (at a time), to the operations can be a bit more efficient. Stream buffers rather than dealing with a fixed size message, are designed more for a continuous stream of bytes (but you can use them for a fixed size message). MessageBuffers add code to handle variable length messages that will move as a single unit through the buffer.