关于信号量一个找了几天的bug，无奈求助大家

15284083060

问题是这样，嵌入式底层采集数据，采集完成之后估计有几兆的文件文件，底层搭建了MQTT以及http服务，同时使用了RT_THREAD的AT组件，最摸不着头脑的问题在于，正常情况下推送消息给服务器是没问题，推送的时候会获取信号量，推送成功会调用推送成功的回调函数释放信号量，这些基本情况的介绍，现在问题是完成数据采集之后，因为信号问题，文件推送超时（超时时间90秒），然后会把推送结果通过mqtt推送给服务器，这个时候问题是看似推送成功了，但是没有，因为没有调用推送成功的回调函数，然后后面的程序就因为这里没有释放信号量而被阻塞。但是同样的地方如果推送成功，并不会出现这种信号量的阻塞，这个BUG估计有些困难，

c2007s

你当然不能依赖推送成功作为唯一条件释放信号量。最起码的是超时释放得有。无论推送是否成功，不能阻塞后续的任务。

jermy_z

c2007s 发表于 2023-4-12 09:10
你当然不能依赖推送成功作为唯一条件释放信号量。最起码的是超时释放得有。无论推送是否成功，不能阻塞后续 ...

说得对   楼主自己都没搞清楚，就在那喊bug bug的   自己用的方法有问题

15284083060

c2007s 发表于 2023-4-12 09:10
你当然不能依赖推送成功作为唯一条件释放信号量。最起码的是超时释放得有。无论推送是否成功，不能阻塞后续 ...

这个问题，我确实不知道是什么原因导致的，但是这个代码是从STM32移植到GD32之后才出现的问题，我觉得唯一能扯上关系的就是GD32的代码运行速度更快一些，基于这个角度我在AT组件里面加一个延时，这个问题就被处理了

15284083060

15284083060 发表于 2023-5-16 11:32
这个问题，我确实不知道是什么原因导致的，但是这个代码是从STM32移植到GD32之后才出现的问题，我觉得唯 ...

时隔三个月，再次回复这个问题，加延时确实规避这个问题，但不是问题的本质，先说前提，接收这个项目之后发现之前开发把任务优先级弄反了，该设置成最高的是最低，反之亦然，然后有一个存在弊病的任务就是LED的任务，这个任务的优先级最高，而且切换的时候是在临界区里面，就是这个临界区导致了很多问题，这个信号量所在的任务，优先级为5，会被抢占，所以在任务运行的过程中，失败会尝试发送三次，第二次不会释放信号量，第三次失败之后会释放信号量，等于第二次就是一个真空期，然后刚好在第二次尝试推送，接收的时候被抢占，进入临界区，然后中断就被延时，接收不到应该接收的错误回复，于是就卡死了，