16592 views|0 replies

361

Posts

5

Resources
The OP
 

【RT-Thread】Reading Notes (3) Critical Section Protection, Objects, and Containers [Copy link]

This post was last edited by dong2213dong on 2019-5-8 17:31 1. Critical section protection A critical section refers to a section of code that cannot be interrupted during execution. This critical section most often occurs in the operation of global variables. Here is a brief record of the reasons. For example, two threads will operate the same global variable. If the system schedules another thread to be executed while one thread is operating the global variable, the value of the global variable will change after the second thread is executed, and it will be different from the value expected when the first thread was executed. When the first thread is scheduled again, continuing to operate the global variable is likely to cause problems. Therefore, for this global variable, The operation code segment is the critical code segment. Then the critical protection, as the name implies, is to protect the critical code segment from being interrupted during execution. In addition to the system scheduling in the example, another factor that affects the critical segment is the interrupt, because the interrupt can also occur at any time, but the system scheduling is essentially generated only when the interrupt occurs. So the problem is unified. To implement the critical protection, just turn off the interrupt before executing the critical code, and turn on the interrupt after the critical code is executed. The MCU we use will have an instruction to turn off the interrupt, but is it as simple as turning off the interrupt each time the critical code is executed and turning on the interrupt after the execution is completed? This is not the case. The actual situation is a little more complicated, that is, we need to consider the nesting of critical segments. How to solve this problem? The solution is to save the current interrupt status (on or off) and then turn off the interrupt before entering the critical section code. After exiting the critical section code, do not directly turn on the interrupt, but restore the interrupt register to the state before entering the critical section. In this way, if the interrupt is turned off before entering the critical section, then after exiting the critical section, the interrupt status is restored and it is still turned off. This solves the problem of nested critical sections (of course, if there are several layers of nested critical sections, several variables are needed to save the interrupt status). The interrupt turn-on and turn-off code is implemented in assembly language, so there is no need to post the code. 2. Objects The book explains: In RT-Thread, all data structures are called objects. I am actually a little confused about this "data structure", and I don't quite understand why RT-Therad uses the word "object". If this "object" comes from the "object" in object-oriented programming language, then according to my own understanding, in object-oriented programming language, "object is the instantiation of class", and "class" can be understood as a data type (because some books transition from C language structure to class, and class is just a structure with function introduced, so the book explains that "all data structures are called objects", then does this data structure refer to the construction type, or the actual variable defined by the construction type? ... However, the book also has the object data type, so in this case, the object can still be loosely understood as the construction type, so I understand that the object here is just an introduced noun) 3. ContainersThe book says that a container is essentially an array, so this is not difficult to understand, and it can be roughly guessed from the literal meaning. However, there is a passage in the book that says that in rtt, whenever a user creates an object, such as a thread (this place is also the "data structure" that I was confused about above. According to the understanding that a thread is a function, that is, a piece of program code, this can also be called a data structure...), the object will be placed in a place called a container, , then the "object" is something that actually occupies memory space. Well, my knowledge is limited, and my brain is a bit confused. I will leave a mark first to know that this is the case. As the book says: At present, we only need to know that all created objects will be placed in containers. I will slowly understand it laterThis content is created by EEWORLD forum user dong2213dong. If you need to reprint or use it for commercial purposes, you must obtain the author's consent and indicate the source
This post is from Embedded System

Just looking around
Find a datasheet?

EEWorld Datasheet Technical Support

EEWorld
subscription
account

EEWorld
service
account

Automotive
development
circle

About Us Customer Service Contact Information Datasheet Sitemap LatestNews

Room 1530, Zhongguancun MOOC Times Building, Block B, 18 Zhongguancun Street, Haidian District, Beijing 100190, China Tel:(010)82350740 Postcode:100190

Copyright © 2005-2024 EEWORLD.com.cn, Inc. All rights reserved 京B2-20211791 京ICP备10001474号-1 电信业务审批[2006]字第258号函 京公网安备 11010802033920号
快速回复 返回顶部 Return list