A multi-processor task management method and system

Abstract

The application discloses a kind of multi-processor task management method and system, the method includes obtaining device input information, and device input information is converted into standard input event;Priority score is set to standard input event, and standard input event is dynamically filtered and sorted according to device working state, priority score;Event subscription table and application task list are obtained, and event subscription table at least records the event type set subscribed by each task;After standard input event and corresponding subscription event set in event subscription table are matched successfully after being dynamically filtered and sorted, standard input event is distributed to corresponding task node;Callback execution function in task node is called, and corresponding callback processing program is executed according to the processor core type of task running in task node.The application realizes the decoupling between input event and task execution logic, solves the problem that different subsystem input processing logic is independent in prior art.

Description

Technical Field

[0001] This invention relates to the field of processor task control technology, and more specifically to a multiprocessor task management method and system. Background Technology

[0002] As wearable devices gain greater computing power, systems like smartwatches typically integrate multiple input devices, including physical buttons, touchscreens, gesture sensors (such as wrist raise detection), health sensors (such as heart rate and blood oxygen sensors), and voice wake-up modules. In existing systems, these input signals are usually processed independently by their respective subsystems: for example, button events are handled by the power management subsystem, touch events by the user interface subsystem, sensor events by the health monitoring subsystem, and gesture events by a separate motion sensing subsystem. Each subsystem has its own event receiving and processing logic, running concurrently within the same system.

[0003] In existing technologies, because the input processing logic of different subsystems is independent and lacks a unified input abstraction layer, adding or changing input sources requires modifications to multiple code sections, resulting in poor system scalability and maintainability. Furthermore, the processing priority of input events in each subsystem is entirely determined by its internal logic, making it impossible to perform unified dynamic priority scoring and filtering based on the overall device status (such as low-power mode, user scenario switching, etc.). This makes it difficult to optimize system power consumption, and input events with high real-time requirements (such as health alarms) may be delayed in response by lower-priority background tasks. Finally, the lack of a standardized transmission path between input events and task execution makes it impossible to achieve unified event distribution and scheduling across subsystems.

[0004] Therefore, a new technological solution is needed. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a multiprocessor task management method and system to at least solve the problem that the input processing logic of different subsystems is independent of each other in the prior art.

[0006] The embodiments of the present invention provide the following technical solutions: This invention provides a multiprocessor task management method applied to a main control core, the method comprising: Acquire device input information and convert the device input information into standard input events; The standard input events are assigned priority scores, and the standard input events are dynamically filtered and sorted according to the device's operating status and the priority scores. Obtain an event subscription table and an application task list. The event subscription table records at least the set of event types subscribed to by each task. The application task list includes multiple task nodes, and each task node includes the processor core for task execution and a callback execution function. After the standard input event, which has been dynamically filtered and sorted, is successfully matched with the corresponding set of subscribed events in the event subscription table, the standard input event is distributed to the corresponding task node. The callback execution function in the task node is invoked, and the corresponding callback handler is executed according to the processor core type of the task running in the task node.

[0007] Preferably, the event subscription table further includes a task identifier, the processor core where the task resides, the task subscription priority weight, and the callback execution function entry point. The task node further includes a task type, the current status of the task, and a subscription relationship pointing to the task subscription table.

[0008] Preferably, the method further includes: Based on changes in the device's operating status, the set of event types subscribed to by the corresponding task in the event subscription table is dynamically modified.

[0009] Preferably, setting priority scoring for the standard input event includes: The priority score of the standard input event is dynamically calculated based on its urgency level, interaction level, and the current device operating status.

[0010] Preferably, executing the corresponding callback handler based on the processor core type in the task node includes: Determine the processor core type in the task node; if it is a local processor core, execute the callback logic on the local processor core. If it is a remote processor core, control commands are sent to the remote processor core through a cross-core communication mechanism. The control commands include a target task identifier and an input event payload.

[0011] Preferably, a state image copy is created in the main control core for the remote task running on the remote processor core. The state image copy includes at least the running state, resource state, and execution result state of the remote task, and the state image copy is associated with the corresponding task node through the state image reference recorded in the task node. When the state of the remote task changes, the changed state is synchronized to the master control core through cross-core communication to update the state mirror copy; The master control core dynamically adjusts the event subscription relationship of the remote task or controls the execution of the remote task based on the updated state mirror copy.

[0012] Preferably, after the master control core sends a control command to the remote processor core, the remote processor core executes a callback process and generates an execution result. The execution result, as a state change, is synchronized to a state mirror copy of the master control core through cross-core communication. The master control core then adjusts the task subscription relationship or control command again based on the execution result.

[0013] This invention also provides a multiprocessor task management system, including: An input abstraction layer is used to acquire device input information and convert the device input information into standard input events; An event priority filtering layer is used to set priority scores for the standard input events and to dynamically filter and sort the standard input events according to the device's working status and the priority scores. The task subscription management module is used to maintain an event subscription table, which records at least the set of event types subscribed to by each task; The application task list module is used to maintain the application task list, which includes multiple task nodes. Each task node includes a processor core for task execution and a callback execution function. The event distribution module is used to distribute the standard input event to the corresponding task node after the standard input event, which has been dynamically filtered and sorted, is successfully matched with the event subscription table. The callback execution module is used to call the callback execution function in the task node and execute the corresponding callback handler according to the processor core type in the task node.

[0014] Preferably, the event subscription table further includes a task identifier, the processor core where the task resides, the task subscription priority weight, and a callback execution function entry point; the task node further includes a task type, the current task status, and a reference pointing to the subscription relationship in the event subscription table; or The task subscription management module is also configured to dynamically modify the set of event types subscribed to by the corresponding task in the event subscription table according to changes in the device's operating status.

[0015] Preferably, the system further includes: The task status mirror module is used to create and maintain a status mirror copy for a remote task running on a remote processor core in the main control core. The status mirror copy includes at least the running status, resource status and execution result status of the remote task. The task status mirror module interacts with the remote processor core through a cross-core communication mechanism. When the status of the remote task changes, the changed status is synchronized to the main control core to update the status mirror copy. The callback execution module or the event subscription management module dynamically adjusts the event subscription relationship of the remote task or controls the execution of the remote task based on the updated state mirror copy.

[0016] Compared with the prior art, the beneficial effects that the at least one technical solution adopted in the embodiments of the present invention can achieve include at least: This invention provides a multiprocessor task management method that unifies multi-source device inputs into standard input events and dynamically filters and sorts them based on priority scores and device operating status. Only valid events are sent to the task subscription management module for matching, thus decoupling input events from task execution logic. Simultaneously, an event subscription table is used to uniformly record the dynamic subscription relationship between tasks and events. Matched events are distributed to the corresponding task nodes, and callback handlers are executed according to the processor core type. This transforms task scheduling from traditional static binding to a flexible and configurable table-driven approach, significantly improving system scalability and maintainability, effectively reducing processor wake-ups and power consumption overhead caused by unnecessary events, enhancing the real-time response capability of high-priority events, and supporting unified scheduling of local and remote tasks by the main control core, laying the foundation for cross-core task management. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments 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.

[0018] Figure 1 This is a flowchart of a multiprocessor task management method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the overall framework of a multiprocessor task management system according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the task dynamic subscription mechanism according to an embodiment of the present invention; Figure 4 This is a schematic diagram of cross-core state mirroring and remote control according to an embodiment of the present invention. Detailed Implementation

[0019] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0020] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. This application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this application, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number and aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0022] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. The drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0023] Additionally, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that practice can be carried out without these specific details.

[0024] With the increasing computing power of wearable devices, systems such as smartwatches commonly adopt heterogeneous multi-core processor architectures, integrating low-power control cores, high-performance application processing cores, and dedicated communication coprocessor cores. In existing systems, different processor cores interact and cooperate through message mechanisms (such as RPMsg or shared memory communication); various input events (including button presses, touches, gestures, health sensor data, and voice wake-up) are handled by their respective subsystems; the triggering relationship between tasks and input events adopts a static binding method, that is, the association is fixed during system design or startup; the state management of cross-core tasks relies on the autonomous maintenance of each core, lacking a unified state model. The above architecture and processing methods constitute the basic implementation form of current wearable device multi-core systems.

[0025] However, existing technical solutions have revealed the following prominent problems in actual operation: First, the static binding between tasks and input events means that tasks cannot dynamically adjust event subscription relationships based on system operating states (such as low power mode, user scenario switching, foreground / background changes), resulting in unnecessary processor wake-ups and power consumption overhead. Furthermore, it is difficult to flexibly enhance the responsiveness to critical events when needed. Second, cross-core tasks lack a unified state model, and the task states on different cores are not transparent to each other, leading to debugging difficulties and challenges in ensuring task consistency.

[0026] In view of this, the inventors conducted long-term observation and performance analysis of the actual operation behavior of existing heterogeneous multi-core systems in wearable devices such as smartwatches. They compared the differences in event response, task scheduling, and power consumption of different processor cores, and conducted in-depth research and improvement exploration on the processing link of multi-source input events, cross-core message interaction latency, and task state synchronization mechanism. They found that the main control processor (such as the main control core of a smartwatch) can be used as the sole task control center. All tasks (including local tasks and remote core tasks) are registered to the main control system in the form of "unified task nodes". Input events do not directly trigger task execution, but are indirectly driven through "task subscription relationship + priority filtering + unified distribution mechanism". Finally, through the cross-core task state mirroring mechanism, the observability and controllability of remote tasks can be achieved.

[0027] Based on this, the embodiments of this specification propose a processing solution: such as Figure 1-2As shown, this invention uses the main control processor core as the sole task control center, abstracts all input device signals into standard events, and after dynamic priority filtering, matches the subscription relationship dynamically maintained by each task through the task subscription management module. The events are then distributed to the corresponding task nodes in the unified application task list. Local callbacks are executed or control commands are sent through cross-core communication according to the processor core type recorded by the task node. At the same time, a state mirror copy is maintained for remote tasks and synchronized in real time. This achieves decoupling of input events and task execution, dynamic adjustment of subscription relationships at runtime, and unified observability and controllability of cross-core tasks, ultimately achieving the system goals of low power consumption, high responsiveness, and easy maintenance.

[0028] The following description, in conjunction with the accompanying drawings, uses a wearable watch as an example to illustrate this solution and the technical solutions provided by various embodiments of this application.

[0029] like Figure 1-2 As shown, this embodiment of the invention provides a multiprocessor task management method applied to a main control core, the method comprising: Step S102: Obtain device input information and convert the device input information into standard input events.

[0030] The device input information includes button input, gesture input, and sensor input information.

[0031] Among them, standard input events are standard event objects that are universally applicable within the system, have a fixed format, and can be processed uniformly after the system translates and formats the raw, messy signals generated by the hardware through the input abstraction layer.

[0032] The format of a standard input event can include event type, event source, event priority, timestamp, event payload, etc.

[0033] In this embodiment, standard input events can be button events, gesture events, and sensor events.

[0034] Step S102 converts the original signal input into a standard input event, thereby solving the problem of complex input event sources and lack of a unified abstraction layer in the prior art.

[0035] Step S104: Set priority scores for standard input events, and dynamically filter and sort the standard input events according to the device's working status and priority scores.

[0036] Specifically, the priority score of a standard input event can be dynamically calculated based on its urgency level, interaction level, and the current device operating status.

[0037] Specifically, assigning priority scores to standard input events allows for grading based on the event's urgency and interaction attributes, thus clearly distinguishing between emergency and ordinary events, and between proactive foreground interactions and reactive background events. For example, life-threatening events such as health alarms and abnormal heart rates can be assigned the highest priority, followed by user-triggered interactive events such as button presses, touches, and wrist raises, while routine background sensor data collection and passive message notifications have the lowest priority.

[0038] The device's operating status includes low battery, silent, motion, screen off, and background running states. The system can dynamically filter out events that are irrelevant, low-value, or unnecessary based on the current actual operating scenario and priority scores. At the same time, it can arrange the processing order of events from high to low priority. For example, in low battery mode, non-core background events are filtered out; in silent mode, notification-type triggering events are blocked; and in motion mode, only motion-related events are retained, thereby achieving scenario-based adaptation of event processing.

[0039] Step S104 assigns priority scores to standard input events and dynamically filters and sorts events based on the current working status of the device. This allows for the priority retention of high-priority events such as health alarms and user-initiated interactions, while filtering out low-value and unnecessary events. This ensures the system can respond quickly to emergency and core events and improve the real-time performance of interactions, while also reducing performance loss and power consumption waste caused by invalid event triggers. This adapts to the low-power and high-real-time operation requirements of wearable devices.

[0040] Step S106: Obtain the event subscription table and the application task list. The event subscription table records at least the set of event types subscribed to by each task. The application task list includes multiple task nodes, and each task node includes the processor core on which the task runs and the callback execution function.

[0041] The event subscription table also includes a task identifier, the processor core where the task resides, the task subscription priority weight, and the callback execution function entry point. The task node also includes the task type, the current status of the task, and a reference to the subscription relationship in the task subscription table.

[0042] like Figure 3 As shown, the event subscription table is the core data table for the dynamic mapping relationship between system maintenance tasks and standard input events. It is managed uniformly by the task subscription management layer and serves as the basis for achieving accurate event-task matching and dynamic scheduling.

[0043] Among them, the EventSubscriptionTable is the core data structure maintained by the task subscription management layer of this invention to record the dynamic mapping relationship between global tasks and standard input events. It is created, managed and supported by the main control core and dynamically updated at runtime. It is the key carrier for decoupling tasks and input events, replacing the traditional static binding method, and supporting accurate routing and distribution of input events. It specifically solves the technical problems of hard-coded binding of tasks and events in heterogeneous multi-core systems, inability to adapt to system state, chaotic event scheduling and uncontrollable power consumption.

[0044] In this invention, the event subscription table uses tasks as the basic management unit, with each task corresponding to an independent subscription entry (SubscriptionEntry). The entry structure fully conforms to the system's standardized definition and specifically includes the following key fields, the meaning and function of which are as follows: The first field, TaskID (Task Identifier), serves as a unique identifier for a task. It is used to accurately distinguish different tasks globally, avoid task identifier conflicts in multi-core scenarios, and is the sole index for event matching, distribution, and cross-core scheduling.

[0045] The second field, CoreType (processor core type where the task resides), is used to mark the actual hardware core location where the task runs, clarifying whether the task is a local task on the main control core or a remote heterogeneous core task such as a low-power control core, application processing core, or communication coprocessor core, providing a basis for target core location for subsequent dual-path execution and cross-core communication.

[0046] The third field, SubscribedEventTypeList (the set of input events currently subscribed to by the task), is used to record the standard input event types that the task actively listens for. This limits the task to responding only to subscribed button events, gesture events, and sensor events, enabling the task to listen to input events on demand and avoiding invalid triggers.

[0047] The fourth field, SubscriptionPriorityWeight, is used to configure the priority of task responses to input events. It combines the priority of the event itself to determine the order of event processing, supports automatic demotion of background tasks and elevation of priority of core tasks, and ensures the real-time performance and reasonable scheduling of the system.

[0048] The fifth field, CallbackEntry (callback execution function entry point), points to the address of the business processing function of the task after the event is triggered. If a match is successful, the logic can be directly called from this entry point to achieve a fast connection between the event and the task execution.

[0049] In some embodiments, the set of event types subscribed to by the corresponding task in the event subscription table can be dynamically modified according to changes in the device's operating status.

[0050] During system operation, the main control core continuously monitors and senses changes in the current operating status of the device. These operating statuses include, but are not limited to, scenarios such as sports mode on / off, silent mode switching, low power mode triggering, task foreground / background state switching, and changes in wearing status. When a change in status is detected, the main control core locates the corresponding task's subscription entry in the event subscription table according to a preset scheduling strategy. It then modifies the SubscribedEventTypeList (the set of input events subscribed to by the current task) field in that entry in real time. Specifically, this includes three adjustment methods: adding subscription event types, deleting subscription event types, and replacing subscription event types. The modification process relies on the DynamicUpdateFlag (dynamic update flag) in the event subscription table. Only when this flag is set is the main control core allowed to add, delete, or replace the subscription event set of the corresponding task. Unauthorized dynamic configuration is prohibited.

[0051] Here is a specific implementation of the present invention: When a user activates sports mode, the main control core adds heart rate sensor events, motion posture sensor events, and wrist gesture events to the subscription event set of the sports task; when a user enters silent mode, the main control core performs a deletion operation on the subscription event set of the notification task, removing unnecessary notification events such as ringtone triggers and vibration alerts; when a task switches from the foreground to the background, the main control core deletes non-core subscription events for that task and simultaneously reduces its subscription priority weight; when the device enters low power mode, the main control core batch deletes non-urgent sensor subscription events for each background task, retaining only core system event subscriptions.

[0052] Through the aforementioned runtime dynamic modification mechanism, the event subscription table can always be matched with the current device scenario, so that tasks only listen to the input events required in the current state, eliminating the system resource and power consumption loss caused by invalid event triggering, while ensuring the priority response capability of core business and emergency events, and making the event scheduling of the entire heterogeneous multi-core system dynamically adaptable, flexible and efficient.

[0053] The ApplicationTaskList is a globally unified task virtualization management core data structure maintained by the application task list layer of this invention for heterogeneous multi-core processor systems. It is independently created, maintained, and scheduled by the main control core. It is used to abstract all local main control core tasks and cross-core tasks running on heterogeneous remote cores such as low-power control cores, application processing cores, and communication coprocessor cores into standardized virtual task nodes for management. It is used to solve the technical defects of traditional heterogeneous multi-core systems, such as physically dispersed tasks, lack of a unified abstract model, and inability to globally schedule and synchronize the state of cross-core tasks.

[0054] In this invention, the application task list uses virtual task nodes (TaskNode) as the smallest management unit. Each task in the system corresponds to a unique task node, and all task nodes together constitute a complete application task list. Regardless of whether a task runs on a local main control core or a remote heterogeneous core, it exists in the list in the form of a unified logical node, realizing undifferentiated virtualized management of local and remote tasks.

[0055] The virtual task node (TaskNode) adopts the standardized structure defined in this invention, and the meaning and function of each field are as follows: CoreType (Processor Core Type): Used to mark the hardware processor core type of the task that the task corresponding to the task node is actually running, clarifying whether the task is a local main control core task or a remote heterogeneous execution core task, and providing a basis for core type determination for the "local / remote dual-path execution" in the subsequent input callback execution stage.

[0056] TaskType: Used to distinguish the business attributes of tasks, including UI tasks, health monitoring tasks, sports tasks, communication coprocessing tasks, etc. It is used to match system business scenarios and event subscription rules, and to support task classification, scheduling and status management.

[0057] TaskState (Current Task State): Used to record the real-time running state of a task, including running, suspended, and waiting states. It provides the main control kernel with a global awareness of the real-time running state of tasks and serves as the state basis for task scheduling, priority adjustment, and execution control.

[0058] EventSubscriptionRef (Subscription Relationship Reference): Used to point to the subscription table entry of the corresponding task in the EventSubscriptionTable in the task subscription management layer, establishing the association link between the task node and the event subscription relationship, so that the master control core can directly obtain the task's subscription event set, priority weight and other scheduling configuration through the task node, and complete the accurate matching of standard input events and tasks.

[0059] CallbackHandler (callback execution function): Used to store the entry address of the business logic processing function corresponding to the task after the standard input event is triggered. After the event is successfully matched, the function can be directly called to execute the task logic, realizing a seamless connection between event routing and task execution.

[0060] StateMirrorRef (State Mirror Reference): Used to associate the state mirror copy of the corresponding remote task in the task state mirror layer, binding the state mirror of the remote task to the task node, so that the master core can directly obtain the real-time status of the remote task through the application task list, supporting the implementation of cross-core task state mirroring mechanism.

[0061] In the system operation process, the application task list is the core data support for the main control core to perform event distribution, task scheduling, execution path determination, and state management: standard input events, after priority filtering and subscription matching, are distributed to the corresponding target task nodes in the application task list; the main control core determines the execution path by reading the CoreType field of the task node, triggers the execution logic through the CallbackHandler field, and synchronizes the remote task status through the StateMirrorRef field; at the same time, the application task list provides a unified task management entry point for dynamic task subscription and cross-core closed-loop control, ensuring that the main control core, as the sole control center, achieves centralized management and control of all tasks in the entire system.

[0062] Step S106 obtains the event subscription table and application task list to provide core data support for the matching, distribution, and subsequent task execution of standard input events. The event subscription table records the set of event types subscribed to by the task to clarify the mapping relationship between events and tasks. The application task list contains task nodes that include the processor cores in which the task runs and the callback execution functions to achieve unified virtualization management of local and remote cross-core tasks. This allows the main control core to accurately match events with target tasks based on the above data, determine the task execution path and business processing logic, effectively solve the problem of physically dispersed tasks and lack of a unified management carrier in heterogeneous multi-core systems, and improve the accuracy of event scheduling and the uniformity and controllability of global task management.

[0063] Step S108: After the standard input event, which has been dynamically filtered and sorted, is successfully matched with the corresponding set of subscribed events in the event subscription table, the standard input event is distributed to the corresponding task node.

[0064] Specifically, the main control core uses the event type of the current standard input event as the matching index to traverse and query the set of subscription event types corresponding to each task in the event subscription table. When the type of the standard input event matches the set of subscription event types of a certain task, it is determined that the event and task subscription relationship is successfully matched. After a successful match, the main control core distributes the standard input event to the virtual task node that uniquely corresponds to the task ID in the application task list according to the task identifier (TaskID) in the event subscription table, thus completing the directed routing of the event from subscription matching to the task node.

[0065] Step S108 relies on the task dynamic subscription mechanism and unified task virtualization mechanism of the present invention to decouple the input event from the task execution logic, replacing the static hard-coded binding method of events and tasks in traditional multi-core systems. This ensures that data is distributed only to tasks that have subscribed to the current event, avoiding invalid triggering and resource waste. At the same time, it relies on the globally unique task node to realize the unified distribution of cross-core events, providing accurate task directions for the master core's subsequent execution callback processing and cross-core scheduling, ensuring the accuracy, orderliness and controllability of system event scheduling.

[0066] Step S110: Call the callback execution function in the task node, and execute the corresponding callback handler according to the processor core type of the task running in the task node.

[0067] Furthermore, executing the corresponding callback handler based on the processor core type in the task node includes: determining the processor core type in the task node; if it is a local processor core, executing the callback logic on the local processor core; if it is a remote processor core, sending control instructions to the remote processor core through a cross-core communication mechanism. The control instructions include the target task identifier and the input event payload.

[0068] Specifically, after an event is distributed to the corresponding task node, the main control core first calls the business logic processing entry point pointed to by the CallbackHandler (callback execution function) in that task node to complete the connection between the event and task execution. Subsequently, the main control core reads the CoreType (processor core type) field in the task node to determine the actual running carrier of the task and executes the dual-path callback processing logic accordingly: if the task node is marked as a local task of the main control core, the main control core directly runs the callback execution function on the local processor core to complete the business logic processing of the local task; if the task node is marked as a remote heterogeneous core task such as a low-power control core, application processing core, or communication coprocessor core, the main control core does not directly execute the callback logic, but instead issues control instructions to the target remote processor core through standardized cross-core communication mechanisms such as RPMsg or shared memory. These instructions carry the target task identifier TaskID and the event payload EventPayload of the standard input event. The remote processor core only passively receives the instructions and executes the corresponding callback processing program without participating in any scheduling decisions.

[0069] Step S110 achieves automatic routing of execution paths through standardized fields of task nodes, decoupling task execution logic from scheduling control logic. This ensures the execution efficiency of local tasks while achieving unified management and control of remote cross-core tasks. It effectively solves the technical problems of scattered execution logic, non-standard cross-core calls, and uncontrollable system behavior in traditional heterogeneous multi-core systems, ensuring the orderliness, consistency, and efficiency of task execution in multi-core systems.

[0070] In some of these embodiments, such as Figure 4 As shown, the method further includes the following steps: Step S112: Create a state image copy for the remote task running on the remote processor core in the main control core. The state image copy includes at least the running status, resource status and execution result status of the remote task, and the state image copy is associated with the corresponding task node through the state image reference recorded in the task node.

[0071] Step S112 is used to build a globally unified standardized state image copy for remote tasks running on remote heterogeneous processor cores such as low-power control cores, application processing cores, and communication coprocessing cores on the main control core side. This solves the problems of no unified state model for cross-core tasks in traditional heterogeneous multi-core systems, the inability of the main control end to perceive the state of remote tasks in real time, difficulty in ensuring the consistency of task states, and the complexity of system debugging and management.

[0072] During system operation, once a remote task is loaded and started on the target remote processor core, the main control core immediately creates a dedicated state image copy for that remote task. This copy is a global state snapshot of the remote task within the main control core, containing at least three core types of information: the running state, resource state, and execution result state. The running state identifies the current working mode of the remote task, such as running, suspended, or waiting. The resource state records the usage of hardware resources such as processor computing power, memory space, and communication channels occupied by the remote task on the remote core. The execution result state stores the output data and instruction execution feedback information after the remote task completes its business processing.

[0073] The aforementioned state mirror copy establishes a binding association with the corresponding remote task node through the StateMirrorRef field built into the virtual task node (TaskNode) in the application task list. The state mirror reference serves as an index identifier, accurately mapping the state mirror copy in the main control core to the target task node in the application task list. This allows the main control core to directly retrieve the state mirror copy of any remote task by traversing the application task list without initiating a real-time status query to the remote core, ensuring the real-time performance and efficiency of status reading.

[0074] Step S112 constructs a unified state image of remote tasks on the main control core side, centralizes and standardizes the management of remote task states that are physically distributed across heterogeneous cores, and provides core data support for the main control core to dynamically adjust task subscription relationships, issue remote control commands, and realize cross-core closed-loop control based on the state image, thereby ensuring the global consistency of task states in heterogeneous multi-core systems.

[0075] Step S114: When the status of a remote task changes, the changed status is synchronized to the main control core through cross-core communication to update the status mirror copy. This ensures that the status mirror copy of the remote task in the main control core is always globally consistent with the actual running status of the task on the remote core, solving the problems of the inability to transmit the status of remote tasks in real time, the lag in status perception at the main control end, and the difficulty in ensuring the consistency of task status in traditional heterogeneous multi-core systems.

[0076] During system operation, when the running status, resource occupancy status, or business execution result status of remote tasks running on remote processor cores such as low-power control core, application processing core, and communication coprocessor core change, the remote processor core, as the execution plane, only passively triggers the status synchronization process and does not make any scheduling decisions. The remote core packages the latest status data of the remote task after the change and transmits it to the main control core in real time through the cross-core communication mechanism of RPMsg or shared memory standard specified in this invention.

[0077] After receiving the state synchronization data, the master control core accurately locates the corresponding state mirror copy of the remote task in the master control core based on the StateMirrorRef field of the corresponding task node in the application task list. It then uses the latest received state data to overwrite and update the content of the original mirror copy, so that the state mirror copy in the master control core is completely synchronized with the actual state of the remote task.

[0078] Through the above real-time status synchronization and image update operations, the master control core can obtain the real running status of all remote tasks without being aware of the process. This provides real-time and accurate status information for subsequent dynamic adjustment of task subscription relationships based on the latest status image, issuance of remote control commands, and realization of cross-core closed-loop control, ensuring the consistency, controllability, and observability of task scheduling in heterogeneous multi-core systems.

[0079] Step S116: Based on the updated state mirror copy, the main control core dynamically adjusts the event subscription relationship of remote tasks or controls the execution of remote tasks. This is used to directly link the real-time status of remote tasks with event subscription and task execution control, solving the problems of each core being autonomous, the main control end being unable to implement precise control based on the real task status, and the unpredictable system behavior in traditional multi-core systems.

[0080] During system operation, after updating the remote task status image copy, the main control core reads three core data types from the status image copy in real time: running status, resource status, and execution result status. Based on the current device operating scenario and scheduling strategy, it autonomously executes two types of core control operations: Firstly, the event subscription relationships of remote tasks are dynamically adjusted. Based on the actual operation of the remote tasks reflected in the status mirror, the main control core modifies the corresponding subscription entries in the event subscription table in real time. This includes adding, deleting, or updating the set of subscription event types and adjusting subscription priority weights. For example, when the status mirror shows that a remote exercise task has completed heart rate data acquisition and entered standby mode, the main control core automatically deletes the task's continuous subscription to heart rate sensor events. When the status mirror shows that the device has entered low power mode, the main control core batch reduces the subscription priority of background remote tasks and deletes non-core event subscriptions, ensuring that the subscription relationships accurately match the actual task status and system resource conditions.

[0081] Secondly, it directly controls the execution flow of remote tasks. Based on the task's running status reflected in the status image copy, the master control core issues task control instructions to the remote processor core, which is the execution plane, through standard cross-core communication mechanisms such as RPMsg or shared memory. This allows the master control core to perform management operations such as starting, suspending, resuming, and stopping remote tasks. For example, if the status image shows that the remote communication task is experiencing resource congestion, the master control core immediately issues a suspend instruction. If the status image shows that the task has completed execution and does not need to continue running, the master control core issues a stop instruction. The remote processor core only passively receives and executes the instructions and does not participate in any decision-making logic.

[0082] In summary, this step deeply binds the state synchronization of cross-core tasks with scheduling control, enabling the main control core to implement precise and adaptive global management based on the real and real-time task state. This not only ensures the efficient utilization of system resources but also achieves consistency, observability, and controllability of task scheduling in heterogeneous multi-core systems, perfectly meeting the low-power and high-real-time design requirements of this invention for wearable device multi-core systems.

[0083] In some embodiments, after the master control core sends control commands to the remote processor core, the remote processor core executes a callback handler and generates an execution result. The execution result, as a state change, is synchronized to a state mirror copy of the master control core through cross-core communication. The master control core then adjusts the task subscription relationship or control commands again based on the execution result to solve the problems of cross-core calls without execution feedback, scheduling state not being able to close the loop, and the master control end being unable to continuously optimize the control strategy based on the actual execution result in traditional multi-core systems.

[0084] During the execution phase, the master control core sends control instructions carrying the target task identifier (TaskID) and standard input event payload (EventPayload) to remote processor cores such as the low-power control core, application processing core, and communication coprocessor core via standard cross-core communication methods such as RPMsg or shared memory. The remote processor cores, acting as the execution plane, only call the callback execution function of the corresponding task according to the instructions after receiving the control instructions, complete the business logic processing, and generate the execution result. The remote processor cores then synchronously transmit the execution result back to the master control core in real time through a predetermined cross-core communication channel in the form of task status data. After receiving this status data, the master control core accurately locates and updates the state mirror copy corresponding to the remote task based on the StateMirrorRef of the task node in the application task list, and writes the execution result into fields such as running status and execution result status. This ensures that the state mirror on the master control core side is completely consistent with the actual execution result of the remote task, ultimately achieving full lifecycle controllability and manageability of cross-core tasks, and enabling real-time linkage between scheduling strategies and the actual execution status of tasks.

[0085] The following is a specific implementation process of an embodiment of the present invention: The first step is to power on the system to complete the initialization of the heterogeneous multi-core processor communication environment and start the task scheduler of the main control core.

[0086] The second step involves various input devices generating raw hardware signals, including button signals, gesture sensing signals, and sensor data acquisition signals.

[0087] The third step involves the input abstraction layer uniformly translating and formatting various raw hardware signals, converting them into standard input events.

[0088] The fourth step is for the event priority filtering layer to score the standard input events by priority and to perform dynamic filtering and sorting based on the device operating status.

[0089] The fifth step involves the task subscription management module matching and retrieving standard input events with each task based on the subscription relationships recorded in the event subscription table.

[0090] Step 6: After successful event matching, the standard input event is dispatched to the corresponding virtual task node in the application task list. Step 7: The system calls the callback execution function configured in the task node to establish the execution association between the event and the task's business logic.

[0091] The eighth step is to distinguish the execution path based on the processor core type recorded in the task node: if it is a local task on the main control core, the business callback logic is executed directly on the local processor core; if it is a remote task on a remote processor core, the control command is sent to the target remote processor core through the RPMsg cross-core communication mechanism, and the remote core executes the corresponding callback processing program.

[0092] Step 9: After the remote task completes its business execution, the running status, resource status, and execution result status are transmitted back to the main control core as status change information through cross-core communication.

[0093] Step 10: The main control core updates the state image copy of the corresponding remote task based on the state image reference, and dynamically adjusts the event subscription relationship or task subscription priority weight of the remote task based on the updated state image copy to achieve adaptive scheduling and control.

[0094] Let's take the actual application scenario of the smartwatch wrist-raise event as an example to illustrate: First, when the user raises their wrist, the watch's gesture sensor generates the corresponding raw gesture signal.

[0095] Second, the original gesture signal is formatted and encapsulated by the input abstraction layer, and converted into a standardized gesture-class standard input event. Third, the motion task pre-subscribes to the wrist-raising gesture event in the event subscription table, and the motion task is triggered to respond after the subscription is matched.

[0096] Fourth, if the motion task is deployed and runs on a low-power remote processor core, the main control core sends control commands to the remote core through RPMsg cross-core communication to start the motion task to execute business logic.

[0097] Fifth, after the exercise task is completed, its operational status information, such as heart rate acquisition and posture monitoring, is synchronously transmitted back to the main control core to update the corresponding status image copy.

[0098] Sixth, when the user turns off the device's motion mode, the main control core actively modifies the set of subscription events for motion tasks in the event subscription table, dynamically deleting related subscription relationships such as wrist-raising gesture events to adapt to the current device operating scenario.

[0099] This invention uses wearable watches as a typical application scenario. The main control core executes a multi-processor task management process, first converting raw input information from various devices such as watch buttons, gestures, and sensors into standardized input events with a unified format. This solves the problem of chaotic input sources and a lack of a unified abstraction layer. Then, by prioritizing these standard input events and combining them with device operating states such as low battery, activity, and silent mode, dynamic filtering and sorting are performed. This ensures that high-priority urgent events are responded to first, and invalid events are filtered out to reduce performance and power consumption. Simultaneously, relying on a structured event subscription table and an application task list containing standardized task nodes, global task virtualization and unified management are achieved, along with decoupling of events and tasks and precise matching and distribution. Finally, based on the processor core type where the task resides, local direct execution or remote cross-core distribution is employed. The system employs a dual-path callback processing method for control commands. By establishing a state image copy of remote tasks on the main control core and synchronizing task state changes across cores to continuously update the image, the main control core can adaptively adjust task subscription relationships and manage the execution of remote tasks based on the latest image. It also forms a closed-loop scheduling mechanism that includes control command issuance, remote execution result generation, state feedback to update the image, and secondary adjustment based on execution results. Overall, it effectively overcomes many shortcomings of traditional wearable device heterogeneous multi-core systems, such as static hard-coded binding of tasks and events, scattered cross-core tasks that are difficult to manage globally, disordered event scheduling, lagging remote task status perception, and lack of scheduling closed loop. It achieves effects such as orderly event scheduling, dynamic adaptation of task subscription scenarios, unified controllable management of local and remote tasks, and global observability of remote task status.

[0100] This invention also provides a multiprocessor task management system applicable to heterogeneous multi-core architectures in wearable watches. The system includes an input abstraction layer, an event priority filtering layer, a task subscription management module, an application task list module, an event distribution module, and a callback execution module. The input abstraction layer acquires device input information and converts it into standard input events. The event priority filtering layer sets priority scores for standard input events and dynamically filters and sorts them based on the device's operating status and priority scores. The task subscription management module maintains an event subscription table, which records at least the set of event types subscribed to by each task. The application task list module maintains an application task list, which includes multiple task nodes, each containing the processor core on which the task runs and a callback execution function. The event distribution module distributes the standard input events to the corresponding task nodes after they have been dynamically filtered and sorted and successfully matched with the event subscription table. The callback execution module calls the callback execution function in the task node and executes the corresponding callback handler based on the processor core type in the task node.

[0101] Specifically, the overall layered and modular design includes an input abstraction layer, an event priority filtering layer, a task subscription management module, an application task list module, an event distribution module, and a callback execution module. Each functional module works collaboratively with the main control core to achieve input event standardization, dynamic filtering, subscription matching, event distribution, and unified scheduling and execution of cross-core tasks in multi-processor scenarios.

[0102] The input abstraction layer is used to collect device input information such as button input, gesture input, and sensor input from wearable watches. It translates and formats the raw, messy signals generated by the hardware into standard input events with a fixed format. These standard input events include fields such as event type, event source, event priority, timestamp, and event payload. Specifically, they are divided into button events, gesture events, and sensor events. This shields the differences in the underlying hardware and solves the shortcomings of existing technologies where the sources of input events are complex and there is no unified abstraction layer.

[0103] The event priority filtering layer is used to set priority scores for standard input events based on their urgency level, interaction level, and device operating status. It distinguishes between urgent / normal events and foreground / background passive events based on the urgency and interaction attributes of the events themselves. At the same time, it dynamically filters and sorts standard input events based on device operating status such as low battery, silent, motion, screen off, and background operation, filtering out low-value irrelevant events and arranging the processing order according to priority. This ensures that high-priority events are responded to first, reducing performance loss and power consumption waste caused by invalid events.

[0104] The task subscription management module is used to maintain the system's global event subscription table. In addition to recording the set of event types subscribed to by each task, this event subscription table is also configured with task identifier, processor core where the task is located, task subscription priority weight, and callback execution function entry point. It serves as the core data table for recording the dynamic mapping relationship between global tasks and standard input events. At the same time, it can dynamically modify the set of subscribed event types for the corresponding task in the event subscription table according to changes in device operating status, realizing adaptive adjustment of task subscription relationships and providing a basis for accurate matching and dynamic scheduling of events and tasks.

[0105] The application task list module is used to maintain a global application task list. The application task list consists of multiple standardized task nodes. Each task node not only records the processor core and callback execution function of the task, but also configures the task type, the current state of the task, a subscription relationship reference pointing to the event subscription table, and a state mirror reference. The module unifies the management of local tasks of the main control core and remote heterogeneous core tasks such as low-power control cores, application processing cores, and communication coprocessing cores into virtual task nodes, realizing cross-core task virtualization and global control.

[0106] The event distribution module is used to match the standard input events, which have been dynamically filtered and sorted, with the subscription event sets of each task in the event subscription table. If the match is successful, the standard input events are accurately distributed to the corresponding task nodes in the application task list according to the task identifier, thereby achieving decoupling of event and task routing and avoiding the triggering of invalid tasks.

[0107] The callback execution module is used to call the callback execution function in the task node and distinguish the execution path according to the processor core type recorded in the task node. If it is a local processor core, the callback logic is executed directly locally. If it is a remote processor core, the module sends a control instruction containing the target task identifier and input event payload to the remote processor core through cross-core communication. The remote processor core then executes the corresponding callback processing program, thereby achieving efficient execution of local tasks and unified management of remote cross-core tasks.

[0108] Furthermore, the event subscription table also includes a task identifier, the processor core where the task resides, the task subscription priority weight, and the callback execution function entry point; the task node also includes the task type, the current task status, and a reference to the subscription relationship in the event subscription table; or The task subscription management module is also configured to dynamically modify the set of event types subscribed to by the corresponding task in the event subscription table based on changes in the device's operating status.

[0109] Furthermore, the system also includes: a task state mirroring module, used to create and maintain state mirror copies for remote tasks running on remote processor cores in the main control core. The state mirror copy includes at least the running state, resource state, and execution result state of the remote task; the task state mirroring module interacts with the remote processor core through a cross-core communication mechanism, and when the state of the remote task changes, it synchronizes the changed state to the main control core to update the state mirror copy; the task subscription management module dynamically adjusts the event subscription relationship of the remote task based on the updated state mirror copy; and the callback execution module issues control commands based on the updated state mirror copy to manage the execution flow of the remote task.

[0110] The task status mirroring module is deployed on the main control core side, specifically for creating and uniformly maintaining status mirror copies of remote tasks running on remote processor cores such as low-power control cores, application processing cores, and communication coprocessor cores. These status mirror copies at least cover the running status, resource status, and execution result status of the remote task, and are associated with the corresponding task node through a built-in status mirror reference. The task status mirroring module interacts with each remote processor core in real time via a cross-core communication mechanism. When the running status, resource usage status, or execution result status of a remote task changes, the remote processor core synchronizes the status change information through cross-core communication. Upon reaching the main control core, the task status mirror module updates the corresponding status mirror copy in a timely manner, ensuring that the mirror data on the main control core side is consistent with the actual running status of the remote task in real time. The task subscription management module can dynamically modify the set of subscription event types and adjust the subscription priority weights of the remote task based on the updated status mirror copy. The callback execution module can also issue control commands to the remote processor core based on the latest status mirror to perform execution control such as starting, suspending, and stopping the remote task. At the same time, the execution results generated by the remote task execution callback will be synchronously updated to the status mirror copy, thereby supporting the system to realize secondary closed-loop control of the remote task subscription relationship and execution strategy based on the execution results.

[0111] In this specification, the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the product embodiments described later, since they correspond to the methods, the descriptions are relatively simple, and the relevant parts can be referred to the descriptions in the system embodiments.

[0112] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method of managing tasks in a multiprocessor system, characterized by, Applied to the main control core, the method includes: Acquire device input information and convert the device input information into standard input events; The standard input events are assigned priority scores, and the standard input events are dynamically filtered and sorted according to the device's operating status and the priority scores. Obtain an event subscription table and an application task list. The event subscription table records at least the set of event types subscribed to by each task. The application task list includes multiple task nodes, and each task node includes the processor core for task execution and a callback execution function. After the standard input event, which has been dynamically filtered and sorted, is successfully matched with the corresponding set of subscribed events in the event subscription table, the standard input event is distributed to the corresponding task node. The callback execution function in the task node is invoked, and the corresponding callback handler is executed according to the processor core type of the task running in the task node.

2. The method of claim 1, wherein, The event subscription table also includes a task identifier, the processor core where the task is located, the task subscription priority weight, and the callback execution function entry point. The task node also includes a task type, the current status of the task, and a reference to the subscription relationship in the task subscription table.

3. The method of claim 2, wherein, Also includes: Based on changes in the device's operating status, the set of event types subscribed to by the corresponding task in the event subscription table is dynamically modified.

4. The method of claim 1, wherein, Setting priority scores for the standard input events includes: The priority score of the standard input event is dynamically calculated based on its urgency level, interaction level, and the current device operating status.

5. The method of claim 1, wherein, The step of executing the corresponding callback handler based on the processor core type in the task node includes: Determine the processor core type in the task node; if it is a local processor core, execute the callback logic on the local processor core. If it is a remote processor core, control commands are sent to the remote processor core through a cross-core communication mechanism. The control commands include a target task identifier and an input event payload.

6. The method according to claim 5, characterized in that, In the main control core, a state image copy is created for the remote task running on the remote processor core. The state image copy includes at least the running state, resource state, and execution result state of the remote task, and the state image copy is associated with the corresponding task node through the state image reference recorded in the task node. When the state of the remote task changes, the changed state is synchronized to the master control core through cross-core communication to update the state mirror copy; The master control core dynamically adjusts the event subscription relationship of the remote task or controls the execution of the remote task based on the updated state mirror copy.

7. The method of claim 6, wherein, After the master control core sends a control command to the remote processor core, the remote processor core executes a callback process and generates an execution result. The execution result, as a state change, is synchronized to a state mirror copy of the master control core through cross-core communication. The master control core then adjusts the task subscription relationship or control command again based on the execution result.

8. A multi-processor task management system, characterized by include: An input abstraction layer is used to acquire device input information and convert the device input information into standard input events; An event priority filtering layer is used to set priority scores for the standard input events and to dynamically filter and sort the standard input events according to the device's working status and the priority scores. The task subscription management module is used to maintain an event subscription table, which records at least the set of event types subscribed to by each task; The application task list module is used to maintain the application task list, which includes multiple task nodes. Each task node includes a processor core for task execution and a callback execution function. The event distribution module is used to distribute the standard input event to the corresponding task node after the standard input event, which has been dynamically filtered and sorted, is successfully matched with the event subscription table. The callback execution module is used to call the callback execution function in the task node and execute the corresponding callback handler according to the processor core type in the task node.

9. The system of claim 8, wherein, The event subscription table also includes a task identifier, the processor core where the task resides, the task subscription priority weight, and the callback execution function entry point; the task node also includes a task type, the current task status, and a reference pointing to the subscription relationship in the event subscription table; or The task subscription management module is also configured to dynamically modify the set of event types subscribed to by the corresponding task in the event subscription table according to changes in the device's operating status.

10. The system of claim 8, wherein, Also includes: The task status mirror module is used to create and maintain a status mirror copy for a remote task running on a remote processor core in the main control core. The status mirror copy includes at least the running status, resource status and execution result status of the remote task. The task status mirror module interacts with the remote processor core through a cross-core communication mechanism. When the status of the remote task changes, the changed status is synchronized to the main control core to update the status mirror copy. The callback execution module or the event subscription management module dynamically adjusts the event subscription relationship of the remote task or controls the execution of the remote task based on the updated state mirror copy.

Images