OSMemGet() 缺憾
UCOSII 是个好东西。唯一感觉任务同步手段好像还是有缺憾。
比如 OSMemGet() ，
如果消费方没有释放内存，生产方，还必须进行延时再申请内存，
如果 OSMemGet() 也带有同步特性，当能申请成功则继续运行，
否则任务挂起等待，
这该多好啊 这也算是缺憾呀?
如果强制要取消费方的内存, 可以使用信号量呀. 不是同步问题解决了 to LZ：
这样做是给应用程序多一个选择，否则的话将总是“死等”在里面。 HWM恰恰是理解反了吧？
UCOS里面的任务挂起不存在死等的情况。
对本生产任务，因为没产品存储场所，当然必须挂起 to 4L：
我说的是给应用程序一个选择。意思是说若没存储资源任务不能继续干任何事的话，就自己等着（同时继续请求存储资源）。但若任务还可以干些其他事的话，则可以先处理一下其他的事项，完了或中途再检测存储资源是否可用。
另外，采用这种方法还可以有效的防止死锁的出现。 LS的思想出发点就不对。
如果一个任务需要等待不同的外部条件，
并且这两个条件可以导致，不分优先权的代码运行片段，
这个任务基本上要考虑分割为不同的任务。
否则会形成扫描运行方式，和大循环无异。
如果用这种思想用OS，还不如大循环来的方便 to 6L：
如果可以有多线程且无线程数限制，那完全可以让一个特定线程去等待。但通常基于MCU的OS和应用程序规模有限，不可能让进程无限制地创建线程（某些OS甚至无此功能）。因此有必要在一个线程内（若无多线程的话则在一个进程内）监控多个对象。处理问题不能走极端，非左即右通常不是最佳选择。 ……经过OS管理的二维数组，即动态内存块的优势在哪里啊？请教大牛们！
页:
[1]