Message processing method and device

Abstract

The embodiment of the invention provides a message processing method and device, and the method comprises the steps: employing a double-thread parallel and double-queue period interchange architecture of a message production thread and a message consumption thread, building a preset period timer, and in each period, according to the current queue identifiers of two message queues in a message queue group, carrying out the message processing of the message production thread and the message consumption thread; and performing interchange processing on the queue identifiers of the two message queues so as to write a bus message through a message production thread and perform consumption execution of the bus message through a message consumption thread based on the queue identifier of the updated message queue group in the period, and then when the starting of the next period is monitored, executing the execution of the bus message through the message consumption thread. And the steps are cyclically executed again. Therefore, the bus thread can continuously and uninterruptedly execute the prepared message queue in the previous period in each period, so that the bus is always in a busy state, the problem of low bus utilization rate is fundamentally solved, and the message processing throughput and response speed of the whole system are improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a message processing method and apparatus. Background Technology

[0002] In aerospace systems employing the 1553B bus, communication is typically scheduled based on a fixed time period (e.g., 100ms). Under this architecture, the number of messages the bus can execute within one cycle is a key parameter for evaluating its communication efficiency and utilization.

[0003] Traditional designs typically employ a serial operating mode where the application and bus messages are executed. This mode is implemented as a sequential loop: first, the application generates a bus message to be sent; then, the bus controller (BC) takes over and executes the transmission of this message; until the message is fully sent and a response is received from the remote terminal (RT), the application remains in a blocked waiting state; only after confirmation that the message has been completed can the application be awakened to continue running, generate the next message, and repeat the above process.

[0004] The inherent drawback of this serial mode is that it leads to deep timing coupling and mutual blocking between the application and the bus controller. This not only wastes the central processing unit (CPU) computing resources when the application is waiting for a bus transfer, but also causes the communication channel to be idle when the bus controller (or bus) is waiting for the application to prepare the next message, resulting in unusable bus idle time and low bus utilization.

[0005] Therefore, low bus utilization is a technical problem that urgently needs to be solved. Summary of the Invention

[0006] In view of this, the purpose of the embodiments of this application is to provide a message processing method and apparatus.

[0007] To achieve the above objectives, in a first aspect, embodiments of this application provide a message processing method, the method comprising: Monitor the periodic start information of the preset periodic timer; In response to the detection of the start information of any period of the preset periodic timer, the queue identifiers of the message queues in the message queue group are swapped to obtain the updated queue identifiers of the message queue group. Based on the updated queue identifier of the message queue group, the message production thread writes bus messages to the message queue group, and the message consumption thread consumes bus messages to the message queue group.

[0008] As an optional embodiment, the message queue group includes a message receiving queue and a message consumption queue. In response to detecting the start information of any period of the preset periodic timer, the queue identifiers of the message queues in the message queue group are swapped to obtain the updated queue identifiers of the message queue group, including: In response to detecting the start information of any period of the preset periodic timer, the queue identifier of the message receiving queue is updated to the message consumption identifier, so as to update the message receiving queue to the message consumption queue; and the identifier of the message consumption queue is updated to the message receiving identifier, so as to update the message consumption queue to the message receiving queue, thereby obtaining the updated queue identifier of the message queue group.

[0009] As an optional embodiment, based on the updated queue identifier of the message queue group, the process includes writing bus messages to the message queue group via a message producer thread and consuming bus messages to the message queue group via a message consumer thread, comprising: Based on the updated message queue group's queue identifier, in response to any bus message produced by the message production thread, the message production thread writes the bus message to the message queue with the message receiving identifier in the message queue group according to the preset message writing rules. Based on the updated message queue group's queue identifier, the message consumption thread retrieves bus messages from the message queues with message consumption identifiers in the message queue group according to preset message consumption rules, and then consumes and executes the bus messages.

[0010] As an optional embodiment, based on the updated message queue group's queue identifier, in response to any bus message produced by the message production thread, the message production thread writes the bus message to the message queue with a message receiving identifier in the message queue group according to a preset message writing rule, including: For a message queue whose updated queue identifier is a message reception identifier, the priority of the bus message is determined by the message production thread in response to any bus message produced by the message production thread. The message production thread writes priority-determined bus messages into a message queue with a message reception identifier.

[0011] As an optional embodiment, based on the updated message queue group's queue identifier, the message consumption thread retrieves bus messages from the message queues with message consumption identifiers in the message queue group according to preset message consumption rules, and consumes and executes the bus messages, including: For message queues whose updated queue identifier is the message consumption identifier, the message consumption thread consumes and executes the bus messages in the message queue based on the priority of the bus messages.

[0012] As an optional embodiment, for a message queue whose updated queue identifier is a message consumption identifier, the message consumption thread consumes and executes bus messages in the message queue based on the priority of bus messages, including: In the message queue whose queue identifier is the message consumption identifier after the update, determine the highest priority bus message in the message queue and the number of the highest priority bus messages; If there are two or more highest priority bus messages, the message consumption thread will consume and execute the two or more highest priority bus messages in the order in which they entered the queue. The highest priority bus message is one, and this highest priority bus message is consumed and executed by the message consumption thread.

[0013] As an optional embodiment, for a message queue whose updated queue identifier is a message consumption identifier, the message consumption thread consumes and executes bus messages in the message queue based on the priority of bus messages, further comprising: In the message queue whose queue identifier is updated to the message consumption identifier, traverse all bus messages to be consumed in the message queue to determine the target message; Update the target priority with the priority of the target message, where the target priority is higher than the priority of all bus messages to be consumed in this message queue; The target message is retrieved from the message queue by the message consumption thread, and then consumed and executed. After the message consumption thread consumes and executes the target message, the following steps are performed: In the message queue whose queue identifier is the message consumption identifier after the update, determine the highest priority bus message in the message queue and the number of the highest priority bus messages; If there are two or more highest priority bus messages, the message consumption thread will consume and execute the two or more highest priority bus messages in the order in which they entered the queue. The highest priority bus message is one, and this highest priority bus message is consumed and executed by the message consumption thread.

[0014] As an optional embodiment, for a message queue whose updated queue identifier is a message consumption identifier, the message consumption thread consumes and executes bus messages in the message queue based on the priority of bus messages, further comprising: For message queues whose updated queue identifier is the message consumption identifier, the execution time of the bus message is determined before any bus message is executed by the message consumption thread; Compare the execution time of this bus message with the remaining time of the current cycle; If the remaining time of the current cycle is greater than the execution time of the bus message, the bus message is executed.

[0015] As an optional embodiment, for a message queue whose updated queue identifier is a message consumption identifier, the message consumption thread consumes and executes bus messages in the message queue based on the priority of bus messages, further comprising: For message queues whose updated queue identifier is the message consumption identifier, when executing any bus message through the message consumption thread, it is determined whether an execution error has occurred. Execution errors include not receiving a status word reply from the remote terminal within a preset timeout period, or the status word of the remote terminal being incorrect, or data verification failing. In response to determining that an execution error flag has occurred, the message type of the bus message is determined. The message type includes normal messages and critical messages. For bus messages of type ordinary message, skip the consumption of the bus message, record the first error log, and then use the message consumption thread to consume the next message bus to be consumed. For bus messages of the critical message type, the bus message is re-inserted into its own consumption queue so that the bus message can be re-consumed and executed by the message consumption thread, and the number of times the bus message has an execution error is recorded. If the number of execution errors exceeds the preset number, a second error log is recorded, and the message bus for the next message to be consumed is connected to the message consumption thread.

[0016] Secondly, embodiments of this application provide a message processing apparatus, the apparatus comprising: The periodic monitoring module is used to monitor the periodic start information of the preset periodic timer; The queue identifier processing module is used to swap the queue identifiers of the message queues in the message queue group in response to the detection of the start information of any period of the preset period timer, so as to obtain the updated queue identifier of the message queue group. The bus message processing module is used to write bus messages to the message queue group through the message production thread and to consume bus messages to the message queue group through the message consumption thread, based on the updated queue identifier of the message queue group.

[0017] The above technical solution has the following beneficial effects: This application adopts a dual-thread parallel architecture of message production thread (message production thread) and message consumption thread (message consumption thread) with dual queue cycle interchange. By creating a preset cycle timer, the queue identifiers of the two message queues in each cycle are interchanged according to the current queue identifiers of the two message queues in the message queue group to obtain the updated queue identifier of the message queue group. Then, based on the updated queue identifier of the message queue group, the message production thread writes bus messages according to the preset message writing rules, and the message consumption thread consumes bus messages according to the preset message consumption rules. Then, when the next cycle is detected to start, the above steps are repeated. In this way, the bus thread can continuously and uninterruptedly execute the message queue prepared in the previous cycle in each cycle, keeping the bus always busy and fundamentally solving the problem of low bus utilization. In addition, the application thread (message producer thread) only needs to focus on producing messages and storing them in the queue, without waiting for the messages to finish executing, while the bus thread (message consumer thread) focuses on scheduling and executing messages, without waiting for new messages to be generated. This separation of responsibilities simplifies the design of the application, eliminating the need to handle complex communication waiting states, improving development efficiency and code maintainability. Furthermore, through the periodic exchange of queue roles, a pipeline with stable overlap between "filling in this cycle" and "execution in the previous cycle" is formed, which parallelizes the two time-consuming processes of application thread processing and bus thread transmission in time, greatly improving the overall message processing throughput and response speed of the system. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of the serial working mode of application program and bus message execution in the related technology of this application embodiment.

[0020] Figure 2 This is a flowchart illustrating one of the message processing methods according to an embodiment of this application.

[0021] Figure 3 This is a second flowchart illustrating a message processing method according to an embodiment of this application.

[0022] Figure 4This is a structural block diagram of a message processing device according to an embodiment of this application.

[0023] Figure 5 This is a structural block diagram of a computer-readable storage medium according to an embodiment of this application.

[0024] Figure 6 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0025] Figure 1 This is a schematic diagram illustrating the structure of the serial operating mode of application program and bus message execution in the related technology of this application embodiment, such as... Figure 1 As shown, the serial operating mode of application and bus message execution is as follows: ① The application generates a bus message; ② The bus thread executes the bus message; ③ The application waits for the message to finish and processes it; ④ The bus thread waits for the application to generate the next message. This involves both the application waiting for bus message execution and the bus waiting for the application to generate a message, during which the bus is idle, thus severely impacting bus utilization.

[0026] To address the technical problems in related technologies, this application provides a message processing method and apparatus. The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0027] One message processing method according to an embodiment of this application employs a parallel thread architecture consisting of message production threads and message consumption threads, as well as a parallel architecture of multiple message queues (e.g., forming a message queue group). Preferably, a dual-thread parallel architecture with alternating cycles of the two queues can be adopted. In this dual-thread architecture, the message production thread is a message production thread, such as an application thread (corresponding to the application program), and the message consumption thread is a message consumption thread, such as a bus thread (corresponding to the bus controller). The two queues can include, for example, two circular queues (e.g., a message receiving queue and a message consuming queue), employing lock-free operations to avoid data copying and thread blocking, thereby improving read / write efficiency. The alternating cycles of the two queues mean that the roles of the two circular queues are interchanged in each cycle. For example, in cycle t1, queue A is the message receiving queue and queue B is the message consuming queue; in cycle t1+1, queue A is replaced by the message consuming queue, and queue B is replaced by the message receiving queue. It is understood that the implementation of multithreading and message queues can also refer to the implementation of the dual-thread, dual-queue architecture, which will not be elaborated further here.

[0028] In this way, the message production thread runs the application logic, generates the bus messages that need to be sent, puts the bus messages into a designated queue (such as a message receiving queue), and then immediately continues to run subsequent programs without waiting for the bus messages to be sent. In this way, the application design is decoupled from bus communication, which becomes simple. The message consumption thread is specifically responsible for executing bus messages, including but not limited to scheduling (determining which message to send first), execution, error handling, timeout judgment, etc. Specifically, it continuously retrieves bus messages from a "consumption queue" (such as a message consumption queue) and executes them. As long as there are messages in the queue, the bus will not be idle, thus improving the utilization of the bus thread.

[0029] Figure 2 This is a flowchart illustrating one embodiment of a message processing method according to this application. Figure 2 As shown, a message processing method may include the following steps: Step 201: Monitor the periodic start information of the preset periodic timer.

[0030] In this embodiment, the preset periodic timer can be a global clock source, such as a hardware timer or a system timer.

[0031] As one implementation approach, if the preset periodic timer is a hardware timer, a dedicated hardware timer or counter, either internal or external to the CPU, can be used. Specifically, this hardware timer is configured to count down after receiving a stable clock signal. When the counter value reaches zero, the hardware timer automatically generates a high-priority interrupt signal. Upon receiving this interrupt signal, the CPU immediately suspends its current task and jumps to a preset interrupt service routine. For example, in an ARM Cortex-M-based aerospace computer module, its SysTick (system tick timer) is used as the periodic timing source. SysTick is configured to generate an interrupt every 100ms. In a PowerPC or SPARC architecture aerospace-grade processor, its general-purpose programmable interval timer is used.

[0032] As an alternative implementation, if the preset periodic timer is an operating system timer, the application or driver can call the operating system's APIs (such as POSIX's `timer_create`, `timer_settime`, or VxWorks's `timerStart`). Specifically, the operating system kernel receives the request, configures a hardware timer, and manages a linked list of software timers. When a hardware interrupt occurs, the operating system kernel's interrupt service routine checks which software timers have expired and then wakes up the corresponding waiting tasks or triggers a callback function. For example, in VxWorks-based or Linux-based systems (with the PREEMPT_RT real-time patch), an application thread can call `semTake` or `sem_wait` to wait for a semaphore released by a periodic timer. When the timer expires, the operating system kernel releases the semaphore, and the waiting application thread and bus thread are simultaneously awakened.

[0033] One implementation mechanism for the preset period timer can be as follows: Step 1: Initialize Configuration For example, during initialization, select an unused high-precision hardware timer (such as the CPU's general-purpose timer GT), then write a value to the timer's period register. This value is calculated based on the system clock frequency and a preset period (such as 100ms). Then, register the timer's interrupt service routine to the operating system's interrupt vector table and set its priority to the highest or second highest to ensure timely response.

[0034] Step Two: Interrupt Service Routine – The System's "Heartbeat" When a hardware timer expires, the CPU hardware automatically saves the current execution context and jumps to an ISR (Interrupt Service Routine). The ISR can first clear the "interrupt pending" bit of the hardware timer (i.e., clear the interrupt flag) to allow the next interrupt to occur, and then issue a synchronization object to the operating system kernel (i.e., issue a synchronization signal). For example, the ISR can release a counter semaphore (e.g., a syncSemaphore) with a count of 1, or the ISR can set an event flag (e.g., CYCLE_START_EVENT). After the ISR finishes execution, the CPU restores the previously saved context.

[0035] As one example, a periodic countdown timer can be maintained within each thread (message producer thread and message consumer thread), i.e., a preset periodic timer. After any thread completes its task for the current period, it will call an API such as osWaitForPeriod(), a function used in Windows to control thread waiting time, and actively enter a blocked state to wait for the timer signal (period start information).

[0036] Step 202: In response to detecting the start information of any period of the preset periodic timer, the queue identifiers of the message queues in the message queue group are swapped to obtain the updated queue identifiers of the message queue group.

[0037] As one possible implementation, the message queue group may include a message receiving queue and a message consuming queue. In this case, step 202 can be implemented as follows: in response to detecting the start information of any period of the preset period timer, update the queue identifier of the message receiving queue to the message consuming identifier, so as to update the message receiving queue to the message consuming queue; and update the identifier of the message consuming queue to the message receiving identifier, so as to update the message consuming queue to the message receiving queue, thereby obtaining the updated queue identifier of the message queue group.

[0038] Optionally, in this embodiment, the queue identifier can be atomically switched after the message production thread and message consumption thread are awakened (e.g., after receiving periodic start information and starting any period) and before executing specific work.

[0039] Optionally, the queue identifiers of the two circular queues can be swapped in the ISR, so that when the two threads are woken up, the two circular queues already have the latest and consistent queue identifiers.

[0040] Optionally, the switch can be performed on the first thread to be awakened, for example, by using a spinlock to protect the switching process, ensuring that only one thread can perform the switching operation and notifying the other thread after the switch is complete.

[0041] As an optional embodiment, the message receiving queue and message consumption queue in the message queue group can be divided into two or two sets of circular queues. By atomically swapping the queue identifiers before executing tasks in the two or two sets of circular queues, the consistency of the queue identifiers can be ensured. This guarantees that the "dual-cycle alternation" (i.e., a parallel working mode based on a fixed time period, dual buffers, and timed swapping of production and consumption roles) can operate accurately and reliably, which is the cornerstone for achieving high bus utilization and high reliability of the entire solution.

[0042] Step 203: Based on the updated queue identifier of the message queue group, write bus messages to the message queue group through the message production thread, and consume bus messages to the message queue group through the message consumption thread.

[0043] In this embodiment, the message production thread and the message consumption thread can be implemented as synchronous waiting and synchronous waking. For example, after completing the work of the previous cycle, both threads are suspended and enter a waiting state, thereby not consuming CPU time and reducing the consumption of computing resources. When the ISR releases the semaphore, the operating system scheduler will wake up both threads simultaneously. Since the message production thread and the message consumption thread may be set to the same priority, they will enter the ready state simultaneously and be scheduled to execute in parallel by the scheduler.

[0044] After the message production thread and message consumption thread enter the ready state, bus message processing is performed. As one embodiment, step 203 can be implemented as follows: based on the queue identifier of the updated message queue group, in response to any bus message produced by the message production thread, the message production thread writes the bus message to the message queue with the message receiving identifier in the message queue group according to the preset message writing rules. Based on the queue identifier of the updated message queue group, the message consumption thread obtains the bus message from the message queue with the message consumption identifier in the message queue group according to the preset message consumption rules, and consumes and executes the bus message.

[0045] In this application, a message receiving identifier can be used to identify a message production queue, and a message consumption identifier can be used to identify a message consumption queue. A circular queue marked with a message receiving identifier can communicate with an application thread (message production thread) to receive bus messages generated by the application thread, while a circular queue marked with a message consumption identifier can communicate with a bus thread (message consumption thread) to consume and execute bus messages through the bus thread. The two circular queues can switch their "identity" by exchanging their queue identifiers. Specifically, the bus messages to be consumed in the circular queue with the message consumption identifier are the bus messages written for the message production thread in the previous cycle. After the queue identifiers are exchanged, the written bus messages become the bus messages to be consumed in the current cycle.

[0046] For example, message queue groups are initialized to form empty circular queues, with queues (groups) A and B initially set to empty. In the current period (e.g., period n), queue (group) A acts as the message receiving queue, while queue (group) B acts as the message consuming queue. Then: In period n-1, queue (group) A is used as the message consumption queue, and queue (group) B is used as the message receiving queue. The message production thread fills queue (group) B with bus messages [Msg_B1, Msg_B2], while the message consumption thread consumes and executes messages [Msg_A1, Msg_A2] from queue (group) A (produced for period n-2). In period n, the queue identifiers of the message queues in the message queue group are swapped. For example, if a preset periodic timer interrupt occurs, the queue roles are atomically swapped: queue (group) A becomes the new message receiving queue, while queue (group) B becomes the new message consuming queue. The message producing thread fills queue (group) A with new messages [Msg_A3, Msg_A4], while the message consuming thread consumes and executes messages [Msg_B1, Msg_B2] (produced in period n-1) from queue (group). In period n+1, the queue identifiers of the message queues in the message queue group are swapped again. For example, if the preset periodic timer interrupt occurs, the queue roles are atomically swapped: queue (group) B becomes the new message receiving queue, while queue (group) A becomes the new message consuming queue. The message production thread fills queue (group) B with new messages [Msg_B3, Msg_B4], while the message consumption thread consumes and executes messages [Msg_A3, Msg_A4] (produced in period n-1) from queue (group).

[0047] In this embodiment, any bus message, from its production to its consumption, is separated by a cycle (produced in cycle n, consumed in cycle n+1). The message consumption thread consumes and executes the bus messages prepared in the previous cycle, so the bus is never idle. The roles of two or more message queues alternate with the cycle, forming a stable and efficient pipeline, ultimately eliminating the idle time of bus threads waiting for messages and achieving extremely high bus utilization.

[0048] Specifically, Figure 3 This is a second flowchart illustrating a message processing method according to an embodiment of this application. (See also...) Figure 3As shown, the two threads (message producer thread and message consumer thread) are the application thread and the bus thread, respectively. The two circular queues (message queues) are queue A and queue B, respectively. The preset periodic timer includes at least period n to period n+2. In any period n, the application thread generates a bus message (e.g., message 1553B in the diagram) and writes it to a circular queue with a message reception identifier. For example, in period n, queue A is a circular queue with a message reception identifier. The bus thread then retrieves bus messages to be consumed from another circular queue, such as queue B in the diagram. It can be understood that the bus messages in queue B are those written by the application thread in the previous period, such as period n-1. When entering the next period n+1, queues A and B switch "identities" (e.g., by atomically switching their queue identifiers). Specifically, as shown... Figure 3 In cycle n+1, queue B becomes a circular queue with a message receiving identifier, and bus messages generated by the application thread are written to queue B. Meanwhile, queue A becomes a circular queue with a message consumption identifier. The bus thread identifies its queue identifier, retrieves the bus messages written in cycle n, and consumes and executes them. In cycle n+2, queues A and B switch roles again, repeating the aforementioned process of writing and consuming bus messages. This separates bus message execution from the application, dividing them into bus threads and application threads. The application thread is responsible for message generation and adding messages to the bus message queue. This simplifies application design and development by eliminating the need to consider the impact of message execution on the application. The bus thread is responsible for message execution, message priority scheduling, error handling, and timeout handling. Because the messages to be executed by the bus thread in each cycle have already been arranged in the previous cycle, the bus thread can execute messages in the bus message queue sequentially without waiting in the current cycle.

[0049] Furthermore, the process of writing the bus message to the message queue with the message receiving identifier in the message queue group according to the preset message writing rules can be specifically implemented as follows: For any bus message produced by the message production thread, the message production thread determines the priority of the bus message according to the updated queue identifier of the message receiving identifier, and then writes the bus message with the determined priority to the message queue with the message receiving identifier. For example, if any bus message A is generated, the message production thread assigns it a priority of 1 (e.g., the highest priority), and then writes it to the message queue with the message receiving identifier. The content of the bus message written to the corresponding queue is shown in Table 1: Table 1

[0050] Furthermore, by having a message consumption thread retrieve bus messages from message queues with message consumption identifiers in the message queue group according to preset message consumption rules, and then consume and execute these bus messages, it can be implemented that for message queues whose updated queue identifiers are message consumption identifiers, the message consumption thread consumes and executes the bus messages in those message queues based on their priority. For example, bus messages with higher priority can be executed first, in descending order of priority.

[0051] Since multiple bus messages with the same priority may appear in the message queue, as an example, in the message queue whose queue identifier is the message consumption identifier after the update, the highest priority bus message in the message queue and the number of highest priority bus messages are determined. If there are two or more highest priority bus messages, the message consumption thread consumes and executes these two or more highest priority bus messages according to the order in which they entered the queue. If there is only one highest priority bus message, the message consumption thread consumes and executes that highest priority bus message. Taking Table 1 as an example, assuming priority 1 is the highest priority, the highest priority bus messages include message 1 and message 4. Since message 1 entered the queue first and message 4 entered the queue later, the execution order is message 1 → message 4.

[0052] Specifically, taking the queue shown in Table 1 as an example, the message scheduling execution process of the bus thread (message consumption thread) can be seen as follows: ① First scan: Found the highest priority of 1. Positions 1 and 4 both have a priority of 1. Based on the rule of "execute the first one in the same priority position" or "execute the one that entered the queue earlier". Execute message 1. ② Second scan: Among the remaining messages, the highest priority is still 1. At this point, only position 4 has a priority of 1. Execute message 4; ③ Third scan: Among the remaining messages, the highest priority becomes 2. Messages at positions 2, 3, and 5 all have a priority of 2. Based on the principle of earlier positions, message 2 is executed. ④ Fourth scan: Among the remaining messages, the highest priority is 2. Message 3 is executed in positions 3 and 5. ⑤ Fifth scan: Execute message 5; The final consumption execution order is: Message 1 → Message 4 → Message 2 → Message 3 → Message 5.

[0053] As another embodiment, the process of consuming and executing bus messages in the message queue based on the priority of the bus messages by the message consumption thread may further include: traversing all bus messages to be consumed in the message queue whose queue identifier is updated to the message consumption identifier to determine the target message; updating the target message's priority to the target priority, wherein the target priority is higher than the priority of all bus messages to be consumed in the message queue; retrieving the target message from the message queue by the message consumption thread for consumption and execution; after the message consumption thread consumes and executes the target message, the following steps are continued: determining the highest priority bus message and the number of highest priority bus messages in the message queue whose queue identifier is updated to the message consumption identifier; in response to the number of two or more highest priority bus messages, consuming and executing the two or more highest priority bus messages by the message consumption thread according to the time order in which the bus messages entered the queue; in response to the number of one highest priority bus message, consuming and executing the highest priority bus message by the message consumption thread. This embodiment aims to dynamically elevate the priority of a bus message already in the queue to the highest level, so that the bus thread can immediately recognize and execute it during the next scan, achieving "queue jumping" and thus quickly responding to real-time changes in the environment.

[0054] To ensure that the bus thread avoids timeouts due to the execution of long messages within the current cycle, thus disrupting the synchronization rhythm of the entire system and fundamentally improving the reliability and predictability of the system, this application also provides the following embodiment: the message consumption thread consumes and executes bus messages in the message queue based on the priority of the bus messages. This further includes: for message queues whose updated queue identifier is a message consumption identifier, before executing any bus message through the message consumption thread, determining the execution time of the bus message, comparing the execution time of the bus message with the remaining time of the current cycle, and executing the bus message if the remaining time of the current cycle is greater than the execution time of the bus message.

[0055] For example, when the bus thread (or the second scene) selects a bus message to be executed from the queue: First, it is necessary to calculate how long it theoretically needs to occupy the bus. The calculation formula is as follows: T_msg = (command word time + data word time * N + status word time + interval time) * retry margin; in: Command word time: The time required for the bus controller (BC) or bus thread to send a command word. A 20-bit command word on the 1553B takes 20 μs at a rate of 1 Mbps.

[0056] Data word time: The time required to transmit one data word (16 bits of data + 3 bits of synchronization / parity check, etc., a total of 20 bits), also 20μs.

[0057] N: The number of data words that need to be transmitted in this message.

[0058] Status word time: The time required for the remote terminal RT to reply with a status word, 20μs.

[0059] Interval time: The necessary response interval between message frames, which is clearly defined in the 1553B protocol (e.g., 4μs~14μs).

[0060] Retry margin: Considering that the 1553B bus may experience transmission errors due to interference and trigger retries, to ensure that everything goes smoothly, the time required for retries is reserved when calculating the time (for example, the time is doubled if calculated based on the maximum number of retries of 1; or a fixed safety buffer time is added).

[0061] For example: A BC to RT “send data” message contains 10 data words, without considering retry margin.

[0062] T_msg = 20μs (command word) + 20μs * 10 (data word) + 20μs (status word) + 10μs (interval) = 250μs.

[0063] Then, the bus thread determines the remaining time using a preset periodic timer. For example, at the beginning of the cycle, the preset periodic timer is set to the total cycle duration (e.g., 100ms), and it decreases as the cycle time passes. Before executing the next message, the bus thread reads the value of the timer to obtain the remaining time of the current cycle.

[0064] Secondly, the bus time occupied by the bus message is compared with the remaining time of the cycle. If the remaining time of the cycle is greater than the remaining time of the current cycle, it is determined that the current remaining time is sufficient to completely transmit the bus message (even if a retry occurs), and the bus thread approves the execution of the bus message. Conversely, if it is determined that the current remaining time is insufficient to safely complete the transmission of the bus message, and forcing execution would likely cause the transmission to be forcibly interrupted at the end of the cycle or encroach on the time of the next cycle, the bus thread will abandon the execution of the bus message. This ensures that the cycle of the bus thread is not disrupted, improving reliability.

[0065] As one implementation, to avoid bus congestion during retransmission, failed execution messages are automatically skipped and logged. For critical messages, a limited automatic retransmission method (retransmission count ≤ 3 times) can be used, thus balancing reliability and timeliness. Specifically, the message consumption thread consumes and executes bus messages in the message queue based on the priority of the bus messages. This also includes: for message queues with updated queue identifiers that are message consumption identifiers, when executing any bus message through the message consumption thread, determining whether an execution error has occurred. Execution errors include not receiving a status word reply from the remote terminal within a preset timeout period, an incorrect status word from the remote terminal, or data verification failure. In response to determining the occurrence of an execution error identifier, the message type of the bus message is determined. The message type includes ordinary messages and critical messages. For bus messages of type ordinary message, skip the consumption and execution of the bus message, record the first error log, and then proceed to the next message bus to be consumed by the message consumption thread. For bus messages of type critical message, re-insert the bus message into its own consumption queue so that the bus message can be consumed and executed again by the message consumption thread, and record the number of execution errors that occurred for the bus message. If the number of execution errors exceeds a preset number, record the second error log, and then proceed to the next message bus to be consumed by the message consumption thread.

[0066] Among these, errors in the remote terminal's status word identifier indicate a transmission error (e.g., message error, format error, etc.), while data verification fails, such as a parity check error (the 1553B hardware typically has this function built-in). Furthermore, the message type of a bus message can be determined based on a predefined field in the message data structure (e.g., the `is_critical` boolean flag, or a rule linked to priority) to determine whether the message is a normal message or a critical message.

[0067] In this embodiment of the disclosure, when the next cycle is started, the aforementioned steps are repeated. For example, if the current cycle is n, when cycle n+1 starts, steps 201 to 203 are entered, and the message production thread (application thread) and message consumption thread (bus thread) restart the task processing operation of cycle n+1.

[0068] As an optional embodiment, this application also provides another implementation scheme, in which the message receiving queue and message consumption queue are divided into multiple sub-queues according to priority. Then, a message production thread writes bus messages with the same priority into the same sub-queue, and a message consumption thread executes the messages in each sub-queue sequentially according to priority. In other embodiments, a message consumption thread can be assigned to each sub-queue, and this message consumption thread is only responsible for executing the messages in its own queue, forming a one-to-one correspondence between message consumption threads and sub-queues, thereby improving message execution efficiency.

[0069] In summary, this application adopts a dual-thread parallel architecture with message production thread and message consumption thread, and a dual-queue cycle interchange. By creating a preset cycle timer, and monitoring the cycle start information of the preset cycle timer, in each cycle, the queue identifiers of the two message queues in the message queue group are interchanged according to the current queue identifiers, resulting in an updated queue identifier for the message queue group. Then, based on the updated queue identifier of the message queue group, the message production thread writes bus messages according to preset message writing rules, and the message consumption thread consumes bus messages according to preset message consumption rules. Then, when the next cycle is detected to be starting, the aforementioned steps are repeated. In this way, the bus thread can continuously and uninterruptedly execute the message queue prepared in the previous cycle in each cycle, keeping the bus always busy and fundamentally solving the problem of low bus utilization. In addition, the application thread (message producer thread) only needs to focus on producing messages and storing them in the queue, without waiting for the messages to finish executing, while the bus thread (message consumer thread) focuses on scheduling and executing messages, without waiting for new messages to be generated. This separation of responsibilities simplifies the design of the application, eliminating the need to handle complex communication waiting states, improving development efficiency and code maintainability. Furthermore, through the periodic exchange of queue roles, a pipeline with stable overlap between "filling in this cycle" and "execution in the previous cycle" is formed, which parallelizes the two time-consuming processes of application thread processing and bus thread transmission in time, greatly improving the overall message processing throughput and response speed of the system.

[0070] Correspondingly, this application also provides a message processing apparatus. Figure 4 This is a structural block diagram of a message processing device according to an embodiment of this application. Figure 4 As shown, a message processing device adopts a dual-thread parallel architecture with message production threads and message consumption threads, and dual-queue cycle switching. The message production thread is a message production thread, and the message consumption thread is a message consumption thread. The device may include: The period monitoring module 401 is used to monitor the periodic start information of the preset period timer; The queue identifier processing module 402 is used to swap the queue identifiers of the message queues in the message queue group in response to the detection of the start information of any period of the preset period timer, so as to obtain the updated queue identifier of the message queue group. The bus message processing module 403 is used to write bus messages to the message queue group by the message production thread based on the updated queue identifier of the message queue group, and to consume bus messages to the message queue group by the message consumption thread.

[0071] In summary, this application adopts a dual-thread parallel architecture with message production thread and message consumption thread, and a dual-queue cycle interchange. By creating a preset cycle timer, and monitoring the cycle start information of the preset cycle timer, in each cycle, the queue identifiers of the two message queues in the message queue group are interchanged according to the current queue identifiers, resulting in an updated queue identifier for the message queue group. Then, based on the updated queue identifier of the message queue group, the message production thread writes bus messages according to preset message writing rules, and the message consumption thread consumes bus messages according to preset message consumption rules. Then, when the next cycle is detected to be starting, the aforementioned steps are repeated. In this way, the bus thread can continuously and uninterruptedly execute the message queue prepared in the previous cycle in each cycle, keeping the bus always busy and fundamentally solving the problem of low bus utilization. In addition, the application thread (message producer thread) only needs to focus on producing messages and storing them in the queue, without waiting for the messages to finish executing, while the bus thread (message consumer thread) focuses on scheduling and executing messages, without waiting for new messages to be generated. This separation of responsibilities simplifies the design of the application, eliminating the need to handle complex communication waiting states, improving development efficiency and code maintainability. Furthermore, through the periodic exchange of queue roles, a pipeline with stable overlap between "filling in this cycle" and "execution in the previous cycle" is formed, which parallelizes the two time-consuming processes of application thread processing and bus thread transmission in time, greatly improving the overall message processing throughput and response speed of the system.

[0072] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0073] This application also provides a computer-readable storage medium 500, such as... Figure 5 As shown, a computer-readable storage medium 500 stores a computer program that, when executed by a processor, implements the steps of the aforementioned message processing method. For example, the computer program is configured to employ a dual-threaded parallel architecture with message production threads and message consumption threads, and a dual-queue cycle-alternating architecture, where the message production thread is a message production thread and the message consumption thread is a message consumption thread. When executed by the processor, it implements the following steps: Monitor the periodic start information of the preset periodic timer; In response to detecting the start information of any period of the preset period timer, the queue identifiers of the message queues in the message queue group are swapped to obtain the updated queue identifiers of the message queue group. Based on the updated queue identifier of the message queue group, the message production thread writes bus messages to the message queue group, and the message consumption thread consumes bus messages from the message queue group.

[0074] In some embodiments, the storage medium is further configured to store program code 501 for performing the following steps: Monitor the periodic start information of the preset periodic timer; In response to detecting the start information of any period of the preset period timer, the queue identifiers of the message queues in the message queue group are swapped to obtain the updated queue identifiers of the message queue group. Based on the updated queue identifier of the message queue group, the message production thread writes bus messages to the message queue group, and the message consumption thread consumes bus messages from the message queue group.

[0075] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. Of course, there are other types of readable storage media, such as quantum memories, graphene memories, etc. It should be noted that the content contained in the computer-readable medium may be appropriately added to or subtracted from the content as required by the legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium may not include electrical carrier signals and telecommunication signals.

[0076] This application also provides an electronic device 600, such as... Figure 6 As shown, it includes one or more processors 601, communication interface 602, memory 603 and communication bus 604, wherein the processor 601, communication interface 602 and memory 603 communicate with each other through communication bus 604.

[0077] Storage 603 is used to store computer programs; When processor 601 executes the program stored in memory 603, it implements the steps of the aforementioned message processing method. For example, when processor 601 executes the program stored in memory 603, it implements the following steps: Monitor the periodic start information of the preset periodic timer; In response to detecting the start information of any period of the preset period timer, the queue identifiers of the message queues in the message queue group are swapped to obtain the updated queue identifiers of the message queue group. Based on the updated queue identifier of the message queue group, the message production thread writes bus messages to the message queue group, and the message consumption thread consumes bus messages from the message queue group.

[0078] The processor 601 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0079] Memory 603 may include mass storage for data or instructions. For example, and not limitingly, memory 603 may include a hard disk drive (HDD), a floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where suitable, memory 603 may include removable or non-removable (or fixed) media. In a particular embodiment, memory 603 is a non-volatile solid-state memory. In a particular embodiment, memory 603 includes read-only memory (ROM). Where suitable, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0080] Communication bus 604 includes hardware, software, or both, for coupling the aforementioned components together. For example, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, the bus may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0081] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0082] While this application provides method operation steps as shown in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive labor. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only execution order. In actual device or client product execution, the method can be executed sequentially as shown in the embodiments or drawings, or in parallel (e.g., in a parallel processor or multi-threaded processing environment).

[0083] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0084] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0085] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0086] This application uses specific embodiments to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A message processing method, characterized in that, The method includes: Monitor the periodic start information of the preset periodic timer; In response to detecting the start information of any period of the preset period timer, the queue identifiers of the message queues in the message queue group are swapped to obtain the updated queue identifiers of the message queue group. Based on the updated queue identifier of the message queue group, the message production thread writes bus messages to the message queue group, and the message consumption thread consumes bus messages from the message queue group.

2. The method according to claim 1, characterized in that, The message queue group includes a message receiving queue and a message consumption queue. In response to detecting the start information of any period of the preset periodic timer, the queue identifiers of the message queues in the message queue group are swapped to obtain the updated queue identifiers of the message queue group, including: In response to detecting the start information of any period of the preset period timer, the queue identifier of the message receiving queue is updated to the message consumption identifier, so as to update the message receiving queue to the message consumption queue; and the identifier of the message consumption queue is updated to the message receiving identifier, so as to update the message consumption queue to the message receiving queue, thereby obtaining the updated queue identifier of the message queue group.

3. The method according to claim 1 or 2, characterized in that, The process of writing bus messages to the message queue group via a message production thread and consuming bus messages to the message queue group via a message consumption thread, based on the updated queue identifier of the message queue group, includes: Based on the updated queue identifier of the message queue group, in response to any bus message produced by the message production thread, the message production thread writes the bus message to the message queue with the message receiving identifier in the message queue group according to the preset message writing rules. Based on the updated queue identifier of the message queue group, the message consumption thread retrieves bus messages from the message queues with message consumption identifiers in the message queue group according to preset message consumption rules, and consumes and executes the bus messages.

4. The method according to claim 3, characterized in that, Based on the updated queue identifier of the message queue group, in response to any bus message produced by the message production thread, the message production thread writes the bus message to the message queue with a message receiving identifier in the message queue group according to a preset message writing rule, including: For a message queue whose updated queue identifier is the message receiving identifier, in response to any bus message produced by the message production thread, the priority of the bus message is determined by the message production thread. The message production thread writes priority-determined bus messages into a message queue with the message reception identifier.

5. The method according to claim 4, characterized in that, The step of retrieving bus messages from message queues with message consumption identifiers in the message queue group based on the updated queue identifier of the message queue group, and consuming and executing the bus messages according to preset message consumption rules, includes: For a message queue whose updated queue identifier is the message consumption identifier, the message consumption thread consumes and executes the bus messages in the message queue based on the priority of the bus messages.

6. The method according to claim 5, characterized in that, The step of processing the message queue whose updated queue identifier is the message consumption identifier, and then having the message consumption thread consume and execute the bus messages in that message queue based on the priority of the bus messages, includes: In the message queue whose updated queue identifier is the message consumption identifier, determine the highest priority bus message in the message queue and the number of the highest priority bus messages; In response to the presence of two or more highest priority bus messages, the message consumption thread consumes and executes these two or more highest priority bus messages in the order in which they entered the queue. In response to the occurrence of one highest-priority bus message, the message consumption thread consumes and executes that highest-priority bus message.

7. The method according to claim 6, characterized in that, The step of consuming and executing bus messages in a message queue whose updated queue identifier is the message consumption identifier, through the message consumption thread based on the priority of bus messages, further includes: In the message queue whose updated queue identifier is the message consumption identifier, traverse all bus messages to be consumed in the message queue to determine the target message; Update the target priority with the priority of the target message, wherein the target priority is higher than the priority of all bus messages to be consumed in the message queue; The target message is retrieved from the message queue by the message consumption thread, and then consumed and executed. After the message consumption thread consumes and executes the target message, the following steps are performed: In the message queue whose updated queue identifier is the message consumption identifier, determine the highest priority bus message in the message queue and the number of the highest priority bus messages; In response to the presence of two or more highest priority bus messages, the message consumption thread consumes and executes these two or more highest priority bus messages in the order in which they entered the queue. In response to the occurrence of one highest-priority bus message, the message consumption thread consumes and executes that highest-priority bus message.

8. The method according to any one of claims 5 to 7, characterized in that, The step of consuming and executing bus messages in a message queue whose updated queue identifier is the message consumption identifier, through the message consumption thread based on the priority of bus messages, further includes: For a message queue whose updated queue identifier is the message consumption identifier, the execution time of the bus message is determined before executing any bus message through the message consumption thread; Compare the execution time of this bus message with the remaining time of the current cycle; If the remaining time of the current cycle is greater than the execution time of the bus message, the bus message is executed.

9. The method according to any one of claims 5 to 7, characterized in that, The step of consuming and executing bus messages in a message queue whose updated queue identifier is the message consumption identifier, through the message consumption thread based on the priority of bus messages, further includes: For a message queue whose updated queue identifier is the message consumption identifier, when executing any bus message through the message consumption thread, it is determined whether an execution error has occurred. The execution error includes not receiving a status word reply from the remote terminal within a preset timeout period, or the status word of the remote terminal is incorrect, or data verification fails. In response to determining that an execution error identifier has occurred, the message type of the bus message is determined, including normal messages and critical messages; For bus messages of type ordinary message, skip the consumption of the bus message, record the first error log, and then use the message consumption thread to consume the next message bus of the bus message; For bus messages of the critical message type, the bus message is re-inserted into its own consumption queue so that the bus message can be re-consumed and executed by the message consumption thread, and the number of times the bus message has an execution error is recorded. If the number of execution errors exceeds a preset number, a second error log is recorded, and the message bus to be consumed by the message consumption thread is then used to process the next message bus to be consumed.

10. A message processing device, characterized in that, Its features are, The device includes: The periodic monitoring module is used to monitor the periodic start information of the preset periodic timer; The queue identifier processing module is used to swap the queue identifiers of the message queues in the message queue group in response to the detection of the start information of any period of the preset period timer, so as to obtain the updated queue identifier of the message queue group. The bus message processing module is used to write bus messages to the message queue group through the message production thread and to consume bus messages to the message queue group through the message consumption thread, based on the updated queue identifier of the message queue group.

Images