按计划这周应该七八两章的,不过在实际操作第六章的例程时,卡住了。虽然验证了结果是对的,可就是推不出这个结果怎么来的,这就很折磨人了。
按照自己的读完程序的想法,5和9的结果应该是反了。。。。可是程序实际跑的结果就是这样的,就是始终找不出自己哪考虑错了。采取了最笨的办法,修改参数
首先改的就是时间片大小参数
- #define THREAD_TIMESLICE 5
结果自然是也没什么改动
一个问题没解决,紧接着来了第二个:
这个在去掉互斥量之后,怎么修改,都一直是起到未保护的效果,按照自己的想法,这个即使去掉后,应该是在一定时间后又是可以的,可实际并未出现。。。。由此,开启了前六章的填坑,发现真的巩固很多知识点。
关于线程的rt_uint32_t tick这个参数,第四章有这样一段描述:“线程的时间片大小......当系统中存在相同优先级的线程时,这个参数指定一次调度器能够运行的最大时间长度”这个实际在例程4-2里已经验证了,线程2是线程1运行时间的一半。
所以,对于线程的几个参数,自己并没有掌握好,从头来过。现在回过来看,例程3-1真的是一个很不错的例程,虽然这个例程出现的比较早。
就是这样每个参数都走一遍,每次只改变一个参数,保证其他参数一致,几次下来,算是把这个程序吃透了,里面的参数也就吃透了。
然而解决问题的真的的转折点,还是在后面修改第一个问题参数中找到了突破口
如果是按照之前的思路,肯定不会出现这个排列,那这个排列是怎么形成的呢?就是这个疑问,解开了前面所有的困惑。
实际就是信号量满了,每次只能释放一个空位。“信号量的值对应信号量对象的实例数目、资源数目”“当信号量的实例数目为零时,再申请该信号量的线程就会被挂起在该信号量的等待队列上”“当信号量大于0时,线程将获得信号量,并且相应信号量值会减1”
之前这个问题同时也解决了,实际可以保护的,只是就是那么一瞬间,因为任务切换都是在延时的时刻,而互斥量,保证了两个自加可以同时运行。延时是进入线程调度的最直接方法,延时等待期间,任务的就绪态决定了运行哪个,不能单看时间片和延时,也不能单看时间片和优先级,这三者是综合影响的。
解决了这些问题,可以继续向后推进了,第七章,线程间通讯。
本帖最后由 数码小叶 于 2019-5-12 20:48 编辑