[RT-Thread reading notes] Week 4: Digest the first six chapters and fill in the gaps

数码小叶

[RT-Thread reading notes] Week 4: Digest the first six chapters and fill in the gaps [Copy link]

  According to the plan, I should have finished chapters 7 and 8 this week, but when I was actually operating the routine in Chapter 6, I got stuck. Although I verified that the result was correct, I just couldn't figure out how this result came about, which was very torturous.

According to my own thoughts after reading the program, the results of 5 and 9 should be reversed. . . . But the actual result of the program is like this, and I still can't find out where I thought wrong. I took the dumbest way and modified the parameters. The first thing I modified was the time slice size parameter. #define THREAD_TIMESLICE 5. Naturally, there was no change. One problem was not solved, and then the second one came: After removing the mutex, no matter how I modified it, it always had the effect of being unprotected. According to my own thinking, even after removing it, it should be possible after a certain period of time, but it did not happen in reality. Therefore, I started to fill in the gaps in the first six chapters, and found that it really consolidated many knowledge points. Regarding the parameter rt_uint32_t tick of the thread, there is a description in Chapter 4: " The time slice size of the thread... When there are threads of the same priority in the system, this parameter specifies the maximum length of time the scheduler can run at one time " This has actually been verified in Example 4-2, where the running time of thread 2 is half of the running time of thread 1. Therefore, I did not have a good grasp of several parameters of the thread, so I started from the beginning. Looking back now, Example 3-1 is really a very good example, although this example appeared earlier.

[/align ]

[align= center]

That's itGo through each parameter, only change one parameter each time, and ensure that the other parameters are consistent. After a few times, I have thoroughly understood this program, and the parameters inside it. However, the real turning point in solving the problem was to find a breakthrough in modifying the first problem parameter later.

If we follow the previous ideas, this arrangement will definitely not appear. Then how is this arrangement formed? It is this question that solves all the previous confusion.

In fact, the semaphore is full and can only release one vacancy at a time. "The value of the semaphore corresponds to the number of instances and resources of the semaphore object" "When the number of instances of the semaphore is zero, the thread that applies for the semaphore will be suspended in the waiting queue of the semaphore" "When the semaphore is greater than 0, the thread will obtain the semaphore, and the corresponding semaphore value will be reduced by 1"

This problem has also been solved before. What can actually be protected is just a moment, because the task switching is at the moment of delay, and the mutex ensures that the two mutexes can run at the same time. Delay is the most direct way to enter thread scheduling. During the delayed waiting period, the ready state of the task determines which one to run. We cannot just look at the time slice and delay, nor can we just look at the time slice and priority. These three are a comprehensive influence.

After solving these problems, we can move on to Chapter 7, Inter-thread Communication.