Implementation method of event notification mechanism under RTX real-time system
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIJING SIMULATION CENT
- Filing Date
- 2023-03-13
- Publication Date
- 2026-06-02
Smart Images
Figure CN116450375B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer technology. More specifically, it relates to a method for implementing an event notification mechanism in an RTX real-time system. Background Technology
[0002] Software porting technology is widely used across operating systems or usage environments. It can adapt existing applications to new platform environments with little or no modification, greatly reducing unnecessary secondary development work.
[0003] Existing technologies for porting VxWorks software to the RTX system have been applied. These technologies utilize middleware to repackage some VxWorks APIs using the RTX system's user API, enabling the porting and adaptation of some VxWorks software functions, including message queues, mutexes, counting semaphores, and binary semaphores. However, some functionalities, such as event notifications (message queue events, semaphore events), are also used. RTX does not provide directly usable APIs for these functions. This functionality allows message queues or semaphores that have registered events to simultaneously notify the receiver of a response via an event mechanism after sending a message or triggering a semaphore. This allows for flexible control of program task execution through the combination of single or multiple event notifications.
[0004] Therefore, it is necessary to provide an implementation method for the event notification mechanism in an RTX real-time system. Summary of the Invention
[0005] One embodiment of the present invention provides a method for implementing an event notification mechanism in an RTX real-time system. To achieve the above objective, the present invention adopts the following technical solution:
[0006] A method for implementing an event notification mechanism in an RTX real-time system, the method comprising:
[0007] The event notification function of VxWorks software is encapsulated using the RTX API, and the events include message queue events and semaphore events;
[0008] Register the current task, mark the event registration in the current task queue attribute array and record the thread, and the function returns normally after completion;
[0009] When an event is received, it is determined whether an event entity has been registered. On the first call, an event entity is created, all events that the call is waiting for are recorded, and at the same time, it starts waiting for all registered events to occur.
[0010] When a message is sent from the message queue, if the message has been registered for a message queue event, the event needs to be sent at the same time as the message is sent. The corresponding time array bit is looked up, the event is marked as sent, and the event notification is performed simultaneously.
[0011] When a semaphore is released and a message is sent, if the message has been registered for a semaphore event, the event needs to be sent at the same time the semaphore is released. The corresponding time array bit is then looked up, the event is marked as sent, and an event notification is sent simultaneously.
[0012] While waiting for event notifications, the system simultaneously evaluates the input optional parameters and determines whether to wait for an event notification: If waiting for a single event notification, and the event has occurred, the system marks the corresponding event bit in the event waiting array, resets the corresponding bit in the event waiting array, and resets the event entity that has occurred; if waiting for all event notifications, and all waiting events have occurred, the system marks all event bits in the event waiting array, resets all bits in the event waiting array, and resets the event entity that has occurred.
[0013] Optionally, registering message queue events or semaphore events for the current task further includes registering message queue events using the msgQEvStart() function and registering semaphore events using the semEvStart() function.
[0014] Optionally, determining whether an event entity has been registered further includes: if the message has been registered for a message queue event, then the event needs to be sent along with the message queue; if it has not been registered, then it is sent as a normal message; if the message has been registered for a semaphore event, then the event needs to be sent along with the release of the semaphore; if it has not been registered, then it is sent as a normal message.
[0015] Optionally, the event notification function uses the RTX event mechanism as the basis for event notification, and is implemented using Event under RTX as the development foundation.
[0016] Optionally, the event notification function enables the message queue or semaphore that has registered the event mechanism to notify the recipient in the form of event communication after sending a message notification or the semaphore is triggered, thereby further triggering subsequent execution.
[0017] Optionally, the event notification mechanism uses a mutex lock to protect the flag, enabling multiple tasks to run simultaneously.
[0018] Optionally, when a message queue sends a message and the message queue has registered a message event, the message queue sending function under the VxWorks system is called. In the middleware, in addition to calling the message queue sending function under RTX, the event sending function is also called. When a semaphore is released and the semaphore has registered a semaphore event, the semaphore release function under the VxWorks system is called. In the middleware, in addition to calling the semaphore release function under RTX, the event sending function is also called.
[0019] Optionally, the waiting for an event is invoked by calling the event waiting function under the VxWorks system, and the event waiting function under RTX is actually called within the middleware.
[0020] A second embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first embodiment.
[0021] A third embodiment of the present invention provides a computing device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in the first embodiment.
[0022] The beneficial effects of this invention are as follows:
[0023] The correctness and excellent performance of the simulated event notification (message queue events, semaphore events) running on the RTX system in this invention are mainly determined by two design parts: the adoption of the RTX event mechanism as the basis for event notification and the handling of the interaction logic between the sender and receiver of message queue events and semaphore events. Adopting the RTX event mechanism as the basis for event notification ensures the real-time requirements of the event notification during waiting and sending, thus ensuring that the real-time performance of the original software is not affected. Through the design of flags such as message queue events, semaphore events, event reception flags, and event status handles, and by using mutex locks to protect these flags, the necessary logic for event notification under VxWorks is implemented, enabling multi-core, multi-threaded applications. The internal logic includes multiple event notifications for task synchronization. Attached Figure Description
[0024] The specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings.
[0025] Figure 1 This diagram illustrates the runtime sequence of the event notification multitasking mechanism.
[0026] Figure 2 This diagram illustrates the design of the event notification registration mechanism of the present invention.
[0027] Figure 3 This diagram illustrates the logical design of the event notification mechanism of the present invention.
[0028] Figure 4 A schematic diagram of the structure of a computer device according to an embodiment of the present invention is shown. Detailed Implementation
[0029] To more clearly illustrate the present invention, the following description, in conjunction with preferred embodiments and accompanying drawings, further clarifies the invention. Similar components in the drawings are indicated by the same reference numerals. Those skilled in the art should understand that the specific description below is illustrative rather than restrictive and should not be construed as limiting the scope of protection of the present invention.
[0030] The approach of this invention is to encapsulate the event notification (message queue events, semaphore events) functionality of VxWorks software using the RTX API. Without altering the original software code's calling format or operational logic, it implements the necessary event notification functionality within an RTX+Windows environment. The ported software exhibits correct operational logic and good real-time performance. The RTX version used in this invention is RTX64 2014, corresponding to the original VxWorks version 6.8. The original software was designed as a multi-core, multi-threaded application, with internal logic including multiple event notifications for task synchronization.
[0031] This project utilizes existing RTX APIs and employs middleware to simulate event notification mechanisms (message queue events, semaphore events). Based on the existing RTX event mechanism, it designs and develops a simulated event notification mechanism to achieve event functionality similar to the VxWorks system.
[0032] In the RTX system user API, the `RtCreateEvent()` function is used to create events. This function creates basic event notifications, using a 32-bit number where each bit is a marker. These events can be used for task synchronization between different threads or processes, or for event triggering, offering good real-time performance with low resource consumption. This invention uses `RtEvent` as the development foundation to implement event notification (message queue events, semaphore events) functionality.
[0033] Event notification is a widely used feature in software written on the VxWorks system. This feature allows message queues or semaphores that have registered an event mechanism to notify the recipient via event communication when a message notification is sent or a semaphore is triggered, thus triggering subsequent execution. This mechanism is particularly suitable for scenarios where multiple events are waiting to be processed simultaneously.
[0034] Example 1
[0035] An implementation method for an event notification mechanism in an RTX real-time system, comprising:
[0036] The event notification (message queue events, semaphore events) functionality of VxWorks software is encapsulated using the RTX API;
[0037] The function returns normally after registering message queue events or semaphore events for the current task, marking the event registration in the current task's queue attribute array, and recording the thread.
[0038] When an event is received, it is determined whether an event entity has been registered. On the first call, an event entity is created, all events that the call is waiting for are recorded, and at the same time, it starts waiting for all registered events to occur.
[0039] When a message is sent from the message queue, if the message has been registered for a message queue event, the event needs to be sent at the same time as the message is sent. The corresponding time array bit is looked up, the event is marked as sent, and the event notification is performed simultaneously.
[0040] When a semaphore is released and a message is sent, if the message has been registered for a semaphore event, the event needs to be sent at the same time the semaphore is released. The corresponding time array bit is then looked up, the event is marked as sent, and an event notification is sent simultaneously.
[0041] While waiting for event notifications, the system simultaneously evaluates the input optional parameters and determines whether to wait for an event notification: If waiting for a single event notification, and the event has occurred, the system marks the corresponding event bit in the event waiting array, resets the corresponding bit in the event waiting array, and resets the event entity that has occurred; if waiting for all event notifications, and all waiting events have occurred, the system marks all event bits in the event waiting array, resets all bits in the event waiting array, and resets the event entity that has occurred.
[0042] In VxWorks 6.8, the `semEvStart()` function is used to register semaphore events, and the `msgQEvStart()` function is used to register message queue events. When a task thread calls `msgQSend()` to send a message, if the thread containing the message has registered a message queue event, the corresponding message queue event notification is sent simultaneously. If not, it is sent as a normal message. When a task thread calls `semGive()` to release a semaphore, if the thread containing the semaphore has registered a semaphore event, the corresponding semaphore event notification is sent simultaneously. If not, it is sent as a normal message.
[0043] This invention maintains an event handle array within a task array class member, containing some attributes and mutex locks for accessing those attributes. The `semEvStart()` or `msgQEvStart()` function registers semaphore events or message queue events for the current task, marking the event registration in the current task's queue attribute array and recording the thread ID. The function returns normally upon completion. When `eventReceive()` is called to receive an event, it checks if an event entity has been registered. On the first call, it actually calls `RtCreateEvent()` under RTX, creating the event entity, recording all events awaited, and simultaneously waiting for all registered events to occur.
[0044] When a message is sent from the message queue, msgQSend() is called. If the message has been registered for a message queue event, the event needs to be sent at the same time as the message. The event sending is actually called in the middleware by eventSend(), which looks up the corresponding time array bit, marks the event for sending, and calls the RTX function RtSetEvent() for event notification.
[0045] When a semaphore is released and a message is sent, semGive() is called. If the message has been registered with a semaphore event, the event needs to be sent at the same time as the semaphore is released. The event sending is actually called in the middleware by eventSend(), which looks up the corresponding time array bit, marks the event for sending, and calls the RTX function RtSetEvent() for event notification.
[0046] When the function waiting to receive an event notification calls eventReceive(), the middleware actually calls RtWaitForSingleObject() and simultaneously checks the optional parameters passed to eventReceive(). If it is waiting for an event notification, after the event occurs, it marks the value of the event bit in the event wait array, resets the value of the event wait array, and calls RtResetEvent() to reset the event entity that has occurred.
[0047] When the function waiting to receive event notifications calls eventReceive(), the middleware actually calls RtWaitForSingleObject() and simultaneously checks the optional parameters passed to eventReceive(). If it is waiting for all event notifications, and if all the waiting events have occurred, it marks all event bits in the event waiting array, resets all bits in the event waiting array, and calls RtResetEvent() to reset all event entities that have occurred.
[0048] In a specific implementation, as shown in the appendix Figure 1 This invention illustrates the timing of notifications between different threads for different events during a multi-threaded processing process:
[0049] 1) Task 1 initially occupies the semaphore. During its resource usage, Task 4 registers a semaphore event and waits for the event to be activated. Task 1 releases the semaphore during execution, and at the same time, the semaphore sends a semaphore event to notify Task 4. After receiving the event notification, Task 4 activates and starts execution.
[0050] 2) Task 2 initially occupies the message queue. During its resource usage, Task 3 registers a message queue event and waits for the event to be activated. While Task 2 is executing, it sends a message to the message queue. At the same time, the message queue sends a message queue event to notify Task 3. After receiving the event notification, Task 3 is activated and begins execution.
[0051] 3) Task 5 registers two types of events simultaneously, including semaphore events and message queue events. During execution, it waits for both events to occur simultaneously before it can activate the events and continue execution. After Task 1 and Task 2 send semaphore events and message queue events in turn, Task 5 waits for both events to be received simultaneously before it can continue execution.
[0052] The actual task logic in use may be more complex or simpler than shown in the diagram. This diagram is only used to illustrate the correct timing of the sending and receiving tasks.
[0053] In this invention, multiple events are simultaneously acquired and released by different threads, including two ordinary events, two semaphore events, and three message queue events. Extensive testing has verified that in the test software, two threads simultaneously acquire two types of events for synchronization, one thread acquires any one ordinary event for synchronization, and one thread acquires multiple semaphore events for synchronization. The entire operation process and real-time performance are completely consistent with the original software operation state under Vxworks. The time notification mechanism works correctly and has excellent performance.
[0054] In one specific embodiment, appendix Figure 2 This is a schematic diagram of the event registration mechanism design for event notification (message queue event, semaphore event) of the present invention. The diagram illustrates the registration mechanism for message queue events and semaphore events.
[0055] 1) When registering a semaphore event, the Vxworks semEvStart() function is called. In the middleware, all semaphore arrays are traversed to find the current bit. After finding it, the current thread ID is obtained, and the current thread ID is assigned to the thread mark bit of the semaphore array. The current event to be registered is assigned to the event bit of the semaphore array, and the semaphore array event is marked as a semaphore event.
[0056] 2) When registering a message queue event, the Vxworks msgQEvStart() function is called to search for the existence of the message queue array in the middleware. Once found, the current thread ID is obtained, and the current thread ID is assigned to the thread flag bit of the message queue array. The current event to be registered is assigned to the event bit of the message queue array, and the event in the message queue array is marked as a message queue event.
[0057] In one specific embodiment, appendix Figure 3 This is a schematic diagram of the interactive logic design of the event notification (message queue event, semaphore event) of the present invention. The diagram shows in detail the logical relationship design between the acquisition and release of event notification (message queue event, semaphore event), and also shows the internal execution logic design of the event notification (message queue event, semaphore event) acquisition and release functions.
[0058] The event mechanism is designed with an array to store all successfully created event handles, as well as the flag bits and flag bit protection locks for each event.
[0059] The following flags are used in this invention:
[0060] eventHandle: Used to record the event handle bit in the task array;
[0061] eventsHaveReceived: Used to mark the event as having occurred in the task array;
[0062] A mutex using flags is as follows:
[0063] HaveReceivedMutex: A flag in the task array that protects the lock;
[0064] eventHandleMutex: The event handle bit protects the lock in the task array;
[0065] Each flag needs to be protected by locking the variable when accessing and modifying it to prevent multiple threads from operating on the variable simultaneously, which could cause system errors.
[0066] Message queue event sending msgQSend()
[0067] 1) First, when sending a message to the message queue, check if the message queue event flag is TRUE;
[0068] 2) If it is a message queue event, then the event sending function is called;
[0069] 3) Perform a bitwise AND operation between the event mask and the 32-bit event array to be sent, and check if the result is non-zero;
[0070] 4) If the result is not 0, then the event is marked as having occurred in eventsHaveReceived;
[0071] 5) At the same time, RtSetEvent resets the event handle bit eventHandle in the current task array and activates the event entity;
[0072] 6) If the result is 0, proceed to the next digit in the loop, repeating the loop a total of 32 times;
[0073] 7) Function returns.
[0074] Semaphore event sending semGive()
[0075] 1) First, when the semaphore is released, check if the semaphore event flag is TRUE;
[0076] 2) If it is a semaphore event, then the event sending function is called;
[0077] 3) Perform a bitwise AND operation between the event mask and the 32-bit event array to be sent, and check if the result is non-zero;
[0078] 4) If the result is not 0, then the event is marked as having occurred in eventsHaveReceived;
[0079] 5) At the same time, RtSetEvent resets the event handle bit eventHandle in the current task array and activates the event entity;
[0080] 6) If the result is 0, proceed to the next digit in the loop, repeating the loop a total of 32 times;
[0081] 7) Function returns.
[0082] Get the event event using eventReceive()
[0083] 1) First, perform a bitwise AND operation between the event mask and the 32-bit array of events to be received, and check if the result is non-zero;
[0084] 2) If the result is not 0, check if the current event handle has been created. If it is empty, create the event entity using RtCreateEvent and record it in the eventHandle array;
[0085] 3) After completion, add the time handle to the wait array lpHandles and record the number of waits (count);
[0086] 4) Determine the value of the event input parameter option: EVENTS_WAIT_ANY returns after waiting for any event, or EVENTS_WAIT_ALL returns after waiting for all events;
[0087] 5) When the eventsHaveReceived array bit is equal to the events array in the events array under the EVENTS_WAIT_ANY condition, the event flag eventsHaveReceived in the task array is set to the initial state, RtResetEvent resets the handles of the events that have occurred, and outputs the recorded event * eventReceived value.
[0088] 6) When the eventsHaveReceived array is not equal to the events array in the eventS_WAIT_ANY case, RtWaitForMultipleObjects waits for any event to occur. After that, the event flag in the event array is set to the initial state, RtResetEvent resets the handles of the events that have occurred, and outputs the recorded event * eventReceived value.
[0089] 7) In the case of EVENTS_WAIT_ALL, RtWaitForSingleObject is called count times to wait for the nth event notification. After all count notifications have been received, and the eventsHaveReceived array bit is equal to the events array, the event flag eventsHaveReceived in the task array is set to the initial state, RtResetEvent resets the handles of the events that have occurred, and outputs the recorded event * eventsReceived value.
[0090] The simulation of the event notification (message queue event, semaphore event) function in the RTX environment of this invention has now been completed.
[0091] Example 2
[0092] A computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the method described in Embodiment 1.
[0093] In practical applications, the computer-readable storage medium can be any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.
[0094] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.
[0095] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.
[0096] Computer program code for performing the operations of this invention can be written in one or more programming languages or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, and C++, as well as conventional procedural programming languages such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).
[0097] Example 3
[0098] like Figure 4 As shown, another embodiment of the present invention provides a structural schematic diagram of a computer device. Figure 4 The computer device 12 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.
[0099] In the appendix Figure 4 In this context, the computer device 12 is represented as a general-purpose computing device. The components of the computer device 12 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and a bus 18 connecting different system components (including system memory 28 and processing units 16).
[0100] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.
[0101] Computer device 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by computer device 12, including volatile and non-volatile media, removable and non-removable media.
[0102] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. Computer device 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (…). Figure 4 Not shown; usually referred to as a "hard drive"). Although Figure 4 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. Memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.
[0103] Computer device 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), and with one or more devices that enable a user to interact with the computer device 12, and / or with any device that enables the computer device 12 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed through input / output (I / O) interface 22. Furthermore, computer device 12 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) through network adapter 20. Figure 4 As shown, network adapter 20 communicates with other modules of computer device 12 via bus 18. It should be understood that, although... Figure 4 As not shown, it can be used in conjunction with computer device 12 with other hardware and / or software modules, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.
[0104] The processor unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing the method provided in Embodiment 1 of the present invention.
[0105] Obviously, the above embodiments of the present invention are merely examples for clearly illustrating the present invention, and are not intended to limit the implementation of the present invention. For those skilled in the art, other variations or modifications can be made based on the above description. It is impossible to exhaustively list all the implementation methods here. All obvious variations or modifications derived from the technical solutions of the present invention are still within the protection scope of the present invention.
Claims
1. A method for implementing an event notification mechanism in an RTX real-time system, characterized in that, The method includes, The event notification function of VxWorks software is encapsulated using the RTX API, and the events include message queue events and semaphore events; Register the current task, mark the event registration in the current task queue attribute array and record the thread, and the function returns normally after completion; When an event is received, it is determined whether an event entity has been registered. On the first call, an event entity is created, all events that the call is waiting for are recorded, and at the same time, it starts waiting for all registered events to occur. When a message is sent from the message queue, if the message has been registered for a message queue event, the event needs to be sent at the same time as the message is sent. The corresponding time array bit is looked up, the event is marked as sent, and the event notification is performed simultaneously. When a semaphore is released and a message is sent, if the message has been registered for a semaphore event, the event needs to be sent at the same time the semaphore is released. The corresponding time array bit is then looked up, the event is marked as sent, and an event notification is sent simultaneously. While waiting for event notifications, the system simultaneously evaluates the input optional parameters and determines whether to wait for an event notification: If waiting for a single event notification, and the event has occurred, the system marks the corresponding event bit in the event waiting array, resets the corresponding bit in the event waiting array, and resets the event entity that has occurred; if waiting for all event notifications, and all waiting events have occurred, the system marks all event bits in the event waiting array, resets all bits in the event waiting array, and resets the event entity that has occurred.
2. The method according to claim 1, characterized in that, The registration of message queue events or semaphore events for the current task further includes registering message queue events using the msgQEvStart() function and registering semaphore events using the semEvStart() function.
3. The method according to claim 1, characterized in that, The determination of whether an event entity has been registered further includes: if the message has been registered for a message queue event, the event needs to be sent along with the message queue; if it has not been registered, it is sent as a normal message; if the message has been registered for a semaphore event, the event needs to be sent along with the release of the semaphore; if it has not been registered, it is sent as a normal message.
4. The method according to claim 1, characterized in that, The event notification function uses the RTX event mechanism as the basis for event notification, and is implemented using Event under RTX as the development foundation.
5. The method according to claim 4, characterized in that, The event notification function enables message queues or semaphores that have registered for the event mechanism to send message notifications or trigger semaphores to notify the recipient in the form of event communication, thereby triggering subsequent execution.
6. The method according to claim 1, characterized in that, The event notification mechanism uses a mutex lock to protect the flag, allowing multiple tasks to run simultaneously.
7. The method according to claim 1, characterized in that, When a message queue sends a message and the message queue has registered a message event, the message queue sending function under the VxWorks system is called. In the middleware, in addition to calling the message queue sending function under RTX, the event sending function is also called. When a semaphore is released and the semaphore has registered a semaphore event, the semaphore release function under the VxWorks system is called. In the middleware, in addition to calling the semaphore release function under RTX, the event sending function is also called.
8. The method according to claim 1, characterized in that, The waiting event call invokes the event waiting function under the VxWorks system, and the event waiting function under RTX is actually called within the middleware.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-8.
10. A computing device, comprising a processor, characterized in that, When the processor executes the program, it implements the method as described in any one of claims 1-8.