CN118245256A

CN118245256A - Method for feeding dogs based on application multithreading

Info

Publication number: CN118245256A
Application number: CN202211668400.0A
Authority: CN
Inventors: 姜从龙
Original assignee: Beijing Ingenic Semiconductor Co Ltd
Current assignee: Beijing Ingenic Semiconductor Co Ltd
Filing date: 2022-12-23
Publication date: 2024-06-25

Abstract

The application provides a method for feeding dogs based on application multithreading, wherein all non-blocking threads in the application of the method participate in a dog feeding process; the watchdog monitors the running state of all non-blocking threads. The application abandons the original framework of the linux watchdog and redefines a set of method for feeding the watchdog by an application layer. The method can enable threads without blocking to participate in the feeding process, monitors the states of all the threads without blocking to the greatest extent, and considers that the application is not working normally as long as one thread does not feed the dogs regularly, thereby triggering a reset signal to reset and restart the microprocessor system.

Description

Method for feeding dogs based on application multithreading

Technical Field

The invention belongs to the technical field of intelligent monitoring, and particularly relates to a method for feeding dogs based on application of multithreading.

Background

The watchdog, also called the watchdog timer (WDT), is a timer circuit, and generally has an input, generally called a dog feeding (KICKING THE dog/SERVICE THE dog), and an output to the RST end of the MCU. And the MCU is prevented from being halted. The function of the watchdog is to prevent the program from endless loops, or running off.

The watchdog is a means for monitoring the running condition of the system, and the running condition of the system is monitored in a mode of combining software and hardware. The software running stably can feed dogs after executing specific instructions, and if the watchdog does not receive a dog feeding signal from the software within a certain period, the system is considered to be faulty, and an interrupt processing program is entered or the system is forced to reset. The timing of enabling the watchdog can be selected according to different working modes after the system is powered on, if the watchdog is enabled, the counter starts to count, and if the watchdog is not fed in time within a set time, the watchdog overtime can occur. The watchdog mainly comprises a register, a counter and a dog call module: the watchdog is basically set through the register, the counter calculates the dog time, and the dog module determines the interrupt or reset mode sent out after the watchdog overtime.

In the linux system, a watchdog framework is realized, and a driver and an application layer program are matched to perform feeding operation. In the driver layer, the main job is to register the character device of the watchdog and create/dev/watchdog node, while registering a series of system call functions such as open, read, write, ioctl, etc. that operate for this node. After the application layer is applied and operated, the square wave level is input to the input end of the watchdog module in the kernel through the operation aiming at the/dev/watch dog node regularly, so that the timer in the watchdog is cleared regularly, the smoothness of the feeding flow is ensured, and when the application stops working for some reasons, the operation of the/dev/watch dog node is stopped, so that the timer of the watchdog module overflows, a reset signal is triggered, and the whole microprocessor system is reset and restarted.

However, current linux watchdog frameworks can guarantee that most applications are monitoring normal operation, but there are some situations that cannot be. For example, in the actual project of the Beijing jun Integrated Circuit, inc. (abbreviated as Beijing jun) product platform, the following is encountered:

the application program comprises a multithreading mechanism and concurrent processing, when triggered by a specific reason, a certain thread or threads are blocked or crashed, and the application is in an abnormal state. However, at this time, the thread feeding the dog still operates normally, which may cause the watchdog to fail to detect such a partial thread failure, and the reset signal is not triggered, so that the abnormal operating state of the application is continued.

Common terminology in the prior art includes:

1. Watchdog (watchdog): the watchdog, also called the watchdog, is essentially a timer circuit, typically having an input called a watchdog and an output, typically connected to the reset terminal of the other part, typically to a single chip or a main control chip. The function of the watchdog is to judge the chip condition by feeding the watchdog periodically, and send a restarting signal to the chip once an error occurs (the watchdog is not fed).

Linux is a self-contained implementation of a watchdog for monitoring the operation of a system, including a kernel watchdog module and a user space watchdog program. The kernel watchdog module communicates with the user space through the character device of/dev/watchdog. The user space program, once it turns on/dev/watch dog device (commonly known as "open dog"), causes a 1 minute timer to be started in the kernel (system default time), after which the user space program needs to ensure that data is written to this device within 1 minute (commonly known as "regular dog feeding"), each write operation causing the timer to be reset. If the user space program has no write operation within 1 minute, the expiration of the timer may result in a system reboot operation. By the mechanism, the core process of the system can be ensured to be in an operation state for most of time, even if the process crashes under specific conditions, the Linux system is restarted (reboot) under the action of the watchdog because the dog cannot be normally timed, and the core process is operated and is used for an embedded system.

2. Feeding dogs: the main control chip inputs square wave signals to the input end of the watchdog module at regular time, the square wave period and interval depend on the watchdog module, and each module has an own application range.

3. Thread: is the minimum unit that the operating system can perform operation scheduling. It is included in the process and is the actual unit of operation in the process. One thread refers to a single sequential control flow in a process, and multiple threads can be concurrent in a process, each thread executing different tasks in parallel.

4. Thread blocking: thread blocking generally refers to a thread pausing during execution to wait for the triggering of a condition.

Ioctl: ioctl (input/output control) is a system call dedicated to device input/output operations, which call is passed into a request code associated with the device, the function of the system call being entirely dependent on the request code.

Ioctl is a function of the device driver that manages the device's I/O channels. The I/O channel management is to control some characteristics of the device, such as the transmission baud rate of the serial port, the rotation speed of the motor, etc. The ioctl function is an attribute component in the file structure, that is, if the driver provides support for ioctl, the user can use the ioctl function in the user program to control the I/O channels of the device. What the user program does is simply telling the driver what it wants to do by means of a command code (cmd), as to how to interpret the commands and how to implement the commands, what the driver is to do.

Disclosure of Invention

In order to solve the above problems, an object of the present application is to: in order to overcome the defects in the situation, the application abandons the native framework of the linux watchdog and redefines a set of method for feeding dogs by an application layer.

Specifically, the invention provides a method based on application multithreading for feeding dogs, which comprises a driving layer operation and an application layer operation, wherein the driving mechanism actively invoked by the application layer is used for feeding dogs, the application layer is used for confirming whether feeding dogs is needed or not, the driving layer is used for realizing the action of feeding dogs, namely, the application layer is used for confirming that feeding dogs are not needed, and the driving layer is used for realizing the specific operation of feeding dogs and further comprises the following steps of; s1 drive layer operation: the driving layer has two core steps;

S1.1, creating character equipment, enabling an application layer to communicate with the driver through a character equipment node of/dev/watchdog;

S1.2, creating a kernel thread, and executing a core operation of feeding the dog, wherein in the kernel thread, judgment is required to be carried out aiming at different threads of the application to determine whether the feeding of the dog is required to be continued or not;

S2, application layer operation: the application layer informs the driver to execute the feeding operation through the/dev/watch node, the logic of the application layer only needs to confirm the non-blocking thread number of the application, and when the application layer is initialized, the application layer informs the watchdog driver, and after the normal logic of all the non-blocking threads is finished, setting operation of ioctl is added.

The step S1.2 further comprises two while loops:

The first cycle is the protection when the application for feeding dogs is not started at the user layer, and the normal operation of the system is ensured by the cycle before the microprocessor system starts from entering the kernel to the application;

The variable thread_mask is that the application notifies the driver through ioctl: how many threads are included in total, and this variable is recorded in bitmap form;

When the variable thread_mask is set to represent that the application is started, the first thread loop exits and enters the second thread loop, at this time, each thread of the variable thread_mask needs to set its bit position continuously through ioctl, and only when the value of thread_mask is identical to that of thread_mask, it proves that all threads are normally set, the operation of feeding dogs is performed, and if the bit position of a certain thread is not correctly set in the thread_mask, it is indicated that the application layer has a certain thread and does not call ioctl in time, the drive layer does not feed dogs, and after the watchdog module timer overflows, a reset signal is triggered, so that the whole system is restarted.

The record in bitmap form is set to 0x111 if there are three threads applied, and set to 0x11111 if there are five threads.

The first while cycle is represented as follows:

the second while cycle is represented as follows:

all non-blocking threads in the application of the method participate in a dog feeding process; the watchdog monitors the running state of all non-blocking threads.

Thus, the present application has the advantages that: the method can enable threads without blocking to participate in the feeding process, monitors the states of all the threads without blocking to the greatest extent, and considers that the application is not working normally as long as one thread does not feed the dogs regularly, thereby triggering a reset signal to reset and restart the microprocessor system.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification, illustrate and together with the description serve to explain the application.

Fig. 1 is a schematic diagram of a general creation flow code of a linux character device.

Fig. 2 is a code schematic of the drive layer.

Fig. 3 is a schematic diagram of application layer test code.

Fig. 4 is a schematic flow chart of the method of the present application.

Detailed Description

In order that the technical content and advantages of the present invention may be more clearly understood, a further detailed description of the present invention will now be made with reference to the accompanying drawings.

The application relates to a method for feeding dogs based on application multithreading, which is shown in fig. 4 and comprises the following steps: s1 drive layer operation:

The driver layer has two core steps, one is to create character equipment, so that the application layer can communicate with the driver through the character equipment node of the dev/watchdog. Secondly, a kernel thread is created, a kernel operation of feeding the dog is executed, and in the kernel thread, judgment is needed to be carried out according to different threads of the application to determine whether the feeding of the dog is needed to be continued or not; in particular, the method comprises the steps of,

S1.1, creating character equipment, enabling an application layer to communicate with the driver through a character equipment node of/dev/watchdog; this is a general creation flow of the linux character device, and a code example is shown in fig. 1.

S1.2, creating a kernel thread, and executing a core operation of feeding the dog, wherein in the kernel thread, judgment is required to be carried out aiming at different threads of the application to determine whether the feeding of the dog is required to be continued or not; specifically, as shown in fig. 2, the driver layer code is the main code of the kernel thread, and includes two while loops, the first loop is the protection when the application requiring feeding the dog at the user layer is not started yet, and the loop can be used to ensure the normal operation of the system before the microprocessor system starts from entering the kernel to the application. the thread_mask variable is a thread logic change that the application notifies the driver via ioctl, see ioctl call in the example code shown in FIG. 2, i.e., the change in thread logic by the change in thread_mask variable, jumps from the first while to the second while: how many threads are included in total, this variable is recorded in bitmap form (if there are three threads applied, it is set to 0x111, if there are five threads, it is set to 0x 11111).

When the variable of the thread_mask is set to represent that the application is started, the first thread loop exits and enters the second thread loop, at this time, each thread of the thread_mask needs to set its own bit by ioctl continuously, see the call of ioctl in the example code shown in fig. 2, that is, the comparison judgment of the thread_mask and the thread_mask, and only when the values of the thread_mask and the thread_mask are identical, it is proved that all threads are set normally, the operation of feeding dogs is performed, and if the bit of a certain thread is not set in the thread_mask correctly, it is indicated that the application layer has a certain thread which does not call ioctl in time, the driver layer cannot feed dogs, and after the watchdog module timer overflows, a reset signal is triggered, so that the whole system is restarted.

S2, application layer operation:

The logic of the application layer is relatively simple, only the number of non-blocking threads of the application needs to be confirmed, the watchdog driver is informed during initialization, and the setting operation of ioctl is added after the normal logic of all the non-blocking threads is finished. As shown in FIG. 3, which is an addition of application layer code logic, the example code has been written, the ioctl call is the way to notify the watchdog driver, and the ioctl set operation is also written as the example code shown in FIG. 3, the ioctl call is the action of notifying and setting.

As shown in FIG. 3, the test code of the application layer application is a test code, before the thread is created, the driver is informed by ioctl, the application has 9 threads, then the threads are idled, each thread has different delay time, through test verification, the test code can feed dogs normally, and when a certain thread is stopped manually, the reset mechanism of the watchdog can be triggered normally. The code shown in FIG. 3 is 9 threads created in the application, each with identical test logic, so only the head and tail are omitted. Only sgm820_ IOCMD _t_x (x=0-8) is the set value of this feeding dog different to let the driver acknowledge which thread fed the dog. The sgm820_ IOCMD _t_x (x=0-8) is defined as a cmd data, such as:

#define SGM820_IOCMD_T_0_IOW('W',2,int)

#define SGM820_IOCMD_T_1_IOW('W',3,int)

#define SGM820_IOCMD_T_2_IOW('W',4,int)

#define SGM820_IOCMD_T_3_IOW('W',5,int)

#define SGM820_IOCMD_T_4_IOW('W',6,int)

#define SGM820_IOCMD_T_5_IOW('W',7,int)

#define SGM820_IOCMD_T_6_IOW('W',8,int)

#define SGM820_IOCMD_T_7_IOW('W',9,int)

#define SGM820_IOCMD_T_8_IOW('W',10,int)。

in summary, the key point and the point to be protected of the present invention are as follows:

1, all non-blocking threads in the application participate in a dog feeding process;

The 2 watchdog monitors the running status of all non-blocking threads.

The above description is only of the preferred embodiments of the present invention and is not intended to limit the present invention, and various modifications and variations can be made to the embodiments of the present invention by those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. The method is characterized by comprising a driving layer operation and an application layer operation, wherein the driving mechanism actively invoked by the application layer is used for feeding the dog, the application layer is used for confirming whether the dog is needed to be fed, the driving layer is used for realizing the action of feeding the dog, namely the application layer is used for confirming that the dog is not needed to be fed, and the driving layer is used for realizing the specific operation of feeding the dog and further comprises the following steps of; s1 drive layer operation: the driving layer has two core steps;

2. The method of claim 1, wherein the step S1.2 further comprises two while loops:

3. A method for application multithreaded dog feeding according to claim 2, wherein the record is in bitmap form, set to 0x111 if there are three threads applied, and set to 0x11111 if there are five threads.

4. A method for application-based multithreaded feeding of dogs in accordance with claim 2 wherein said first while loop is represented as follows:

5. The method for application-based multithreaded feeding of claim 4, wherein the second while loop is represented as follows:

6. The method for feeding dogs based on application multithreading according to claim 1, wherein all non-blocking threads in the application participate in the feeding process; the watchdog monitors the running state of all non-blocking threads.