UCOSIII释放内存的时候还要提供分区，用得很累，你们感觉呢?
如题，UCOSIII提供的内存管理模块以分区和固定大小的块来管理内存，从某一分区获取一个内存块后在释放的时候必须还给对应的分区，否则会出错，而且系统对这种归还内存的时候使用了错误的分区根本就不检测，错了就错了。比如我有两个分区A和B如下：A分区：10个内存块，块大小32字节，（总共就是10*32字节）。创建好了之后形成链表：A1->A2->A3......->A10.
B分区：10个内存块，块大小64字节，（总共就是10*64字节）。创建好了之后形成链表：B1->B2->B3......->B10.
某一流程中从A获取了一块（第一次用就是A1），又从B中获取一块（第一次用就是B1），用完之后故意归还错误（把A1还给B分区，把B1还给A分区），结果不会上报错误，归还完之后A和B分区的空闲链表就成了：
B1->A2->A3......->A10.
A1->B2->B3......->B10.
那么，在实际工程用的时候肯定有多重内存分区，每一个分区的内存块长度肯定不一致（如果一样就没有必要搞多个分区了），获取了内存然后填充再作为消息发出去，另外的任务处理完消息再归还内存，怎么去找对应的分区？根据地址段？
如果根据地址段去找对应的分区行得通，那为什么UCOS不把这个做进去，归还内存的时候提供首地址就可以了，对于用户更加友好。
我想问一下各位，第一你们用不用UCOS的内存管理模块？第二如果用的话怎么用？ 觉得累，就换 RT-Thread 试试吧。 古二真 可以再封装一层，根据所归还内存的地址自动匹配到对应分区。只需建立一个表格，记录分区的地址范围而已。 这种需求其实已经是具体应用的问题了，完全可以用自己的代码来解决问题的。 本帖最后由 armstrong 于 2019-2-25 18:43 编辑
如果你去分析linux内核源码，当你调用kmalloc和kfree时，它就是从不同的内存段里获取，而后归还到不同内存段去的；你需要做的就是这层封装而已。
ucos为了精简，这种需求的代码让开发者自己实现更灵活，不难的。
如果这个功能要ucos来实现（红黑树，哈希，数组），他们会纠结到底用什么算法更灵活，资源占用哪种更少，性能哪种更好等等问题；还增加了配置的复杂度。 因为ucos的内存分配主要目的还是内核自己使用，这样操作mcu的指令最少，对于追求效率的内核来说这样足够了。 这才是安全使用呀，不像PC机，内存大，无所谓。 armstrong 发表于 2019-2-25 18:39
如果你去分析linux内核源码，当你调用kmalloc和kfree时，它就是从不同的内存段里获取，而后归还到不同内存 ...
多谢大侠耐心解释{:handshake:}
页:
[1]