CN109426562B

CN109426562B - priority weighted round robin scheduler

Info

Publication number: CN109426562B
Application number: CN201710761856.4A
Authority: CN
Inventors: 田冰; 王树珂; 路向峰
Original assignee: Beijing Memblaze Technology Co Ltd
Current assignee: Beijing Memblaze Technology Co Ltd
Priority date: 2017-08-30
Filing date: 2017-08-30
Publication date: 2023-10-13
Anticipated expiration: 2037-08-30
Also published as: CN109426562A

Abstract

The application discloses a priority weighted round robin scheduler. For scheduling the processing of a plurality of events. The disclosed scheduler includes: a pending event register, a round robin event selector and a current round robin event enable register; the pending event register indicates one or more events to be scheduled; the toggle event selector is coupled to bits of the pending event register corresponding to one or more toggle events and to the current toggle event enable register; the current round robin event enable register indicates one or more round robin events that may be scheduled; and the rotation event selector selects one of the rotation events to be scheduled according to the indication of the current rotation event enable register.

Description

Priority weighted round robin scheduler

Technical Field

The present application relates to schedulers for embedded CPUs, and in particular, to schedulers for weighted round robin scheduling of events in an embedded system each having a priority.

Background

The respective cores of the embedded multi-core CPU (central processing unit ) process respective tasks. There is a great deal of demand for communication, coordination, among the various cores of the CPU. With ordering between tasks, the start of a task depends on the completion of the processing of the preceding task or tasks. Each core of the CPU processes a plurality of events, and the processing progress of the previous task is known according to the events. For example, events include the occurrence of pending entries in a queue, the passage of a specified length of time, interrupts, custom events generated during processing tasks, and the like.

FIG. 1 is a block diagram of a prior art embedded multi-core CPU system. CPU 0 and CPU 1 are isomorphic or heterogeneous CPU cores and are coupled through buses. Each CPU has a local memory to which the CPU can access with low latency. The CPU is also coupled to an external memory, such as a DDR (Dual Data Rate) memory, through a bus. External memory provides a large storage capacity but has a high access latency. Thus, when the CPU accesses external memory, the high-latency commands are typically buffered by queues. The command may be in the form of a message having a specified data format.

The entries of the queue are messages. The CPU receives messages from the inbound queue and sends messages through the outbound queue. The CPU may have a variety of numbers of queues. Illustratively, referring to FIG. 1, CPU 0 includes an Inbound (Inbound) queue 0, an Inbound (Inbound) queue 1, an Outbound (Outbound) queue 0, and an Outbound (Outbound) queue 1.

To access external memory, CPU 0 adds a message to outbound queue 0. The message is forwarded by the bus to the external memory. The external memory outputs memory access results, which are forwarded to the inbound queue 0 via the bus.

Messages are exchanged between the CPUs through the queues. For example, CPU 0 adds a message to the play queue 1. Messages are bus forwarded to inbound queue 0 of CPU 1. CPU 1 obtains the message sent by CPU 0 from inbound queue 0.

Disclosure of Invention

Taking the example of accessing the external memory, the CPU needs to check the queue status to add a message to the outbound queue and operate when the outbound queue is not full, while there is a longer time from the time the CPU adds a message to the outbound queue to access the external memory until the CPU receives the access result of the external memory from the inbound queue. The CPU needs to schedule other tasks to increase CPU utilization during the period of waiting for the inbound queue to become non-empty, or waiting for the results of accessing external memory. Efficient scheduling of multiple tasks running on a CPU becomes complicated when the CPU processes multiple same or different tasks simultaneously, uses multiple queues, and/or responds to different kinds of events.

The CPU may poll the queue status, add messages to the outbound queue when the outbound queue is not full, or fetch messages from the inbound queue and process when the inbound queue is not empty. But the poll queue status causes a waste of CPU processing power. The CPU may identify the event type and process it in response to interrupts generated by the queue status. However, when a queue event occurs frequently, the CPU burden is severely increased by the overhead of a large number of interrupt processes.

In the desktop CPU and the server CPU, by running the operating system, the operating system schedules a plurality of processes and/or threads running on the CPU, and the operating system selects an appropriate process/thread for scheduling so as to fully utilize the computing capacity of the CPU without excessively intervening the switching between the processes/threads. However, in the embedded multi-core CPU, available memory, CPU processing power, and other resources are limited, and it is difficult to bear the overhead introduced by process/thread management. And some embedded systems have strict requirements on performance, especially task processing delay, and operating systems are also difficult to adapt to this scenario.

When a CPU processes a plurality of tasks, task scheduling also becomes a burden on the CPU, affecting the performance of the task processing system. The task scheduling process is also complex, with high complexity, by programming the CPU for large-scale task scheduling. The load of the CPU is expected to be shared, the efficiency of the task scheduling process is improved, and the realization difficulty of the task scheduling process is reduced.

According to a first aspect of the present application there is provided a first scheduler according to the first aspect of the present application comprising: a pending event register, a round robin event selector and a current round robin event enable register; the pending event register indicates one or more events to be scheduled; the toggle event selector is coupled to bits of the pending event register corresponding to one or more toggle events and to the current toggle event enable register; the current round robin event enable register indicates one or more round robin events that may be scheduled; and the rotation event selector selects one of the rotation events to be scheduled according to the indication of the current rotation event enable register.

According to a first scheduler of the first aspect of the present application, there is provided a second scheduler according to the first aspect of the present application, further comprising an event handling function calling part; the event processing function scheduling component invokes a processing function to process the scheduled rotation event in accordance with the rotation event selector indication.

According to a second scheduler of the first aspect of the present application, there is provided a third scheduler according to the first aspect of the present application, wherein bits of the round robin event enable register corresponding to the first round robin event are cleared in response to the first round robin event being processed.

According to one of the first to third schedulers of the first aspect of the present application, there is provided a fourth scheduler according to the first aspect of the present application, wherein the rotation event selector alternately selects rotation events to be scheduled and which can be scheduled according to the indication of the current rotation event enable register.

According to one of the first to fourth schedulers of the first aspect of the present application, there is provided a fifth scheduler according to the first aspect of the present application, wherein the current rotation event enable register is updated in response to one or more rotation events indicated by the current rotation event enable register being selected which can be scheduled.

According to one of the first to fourth schedulers of the first aspect of the present application, there is provided a sixth scheduler according to the first aspect of the present application, wherein the current rotation event enable register is updated in response to each of the one or more rotation events that can be scheduled as indicated by the current rotation event enable register being selected in turn.

According to a fifth or sixth scheduler of the first aspect of the present application, there is provided a seventh scheduler according to the first aspect of the present application, further comprising a round robin event weight table section; the rotation event weight table section records a plurality of values in order; and sequentially acquiring values from the round robin event weight table for updating the current round robin event enable register, and updating the current round robin event enable register with the acquired values.

According to a seventh scheduler of the first aspect of the present application there is provided an eighth scheduler according to the first aspect of the present application wherein the values recorded by the rotation event weight table means indicate whether one or more rotation events can be scheduled.

According to an eighth scheduler of the first aspect of the present application, there is provided a ninth scheduler according to the first aspect of the present application, wherein a first round-robin event is indicated to be schedulable in a first number of values recorded by the round-robin event weight table assembly; a second round robin event is indicated as being schedulable in a second number of values recorded by the round robin event weight table assembly; and the first number is greater than the second number.

According to a fifth or sixth scheduler of the first aspect of the present application there is provided a tenth scheduler according to the first aspect of the present application further comprising a round robin event weight table assembly; the rotation event weight table component records weights for one or more rotation events.

According to a tenth scheduler of the first aspect of the present application, there is provided an eleventh scheduler according to the first aspect of the present application, further comprising a round robin event enabling setting means and one or more round robin event weight registers; the rotation event enable setting section is processed in response to a first rotation event, selects one of the one or more rotation event weight registers to record that the first rotation event is enabled according to the weight of the first rotation event acquired from the rotation event weight table section.

According to an eleventh scheduler of the first aspect of the present application there is provided a twelfth scheduler of the first aspect of the present application wherein the one or more rotation event weight registers are ordered, one of the one or more rotation event weight registers being selected according to the ordering of the weights of the first rotation event obtained from the rotation event weight table section in the set of weights of rotation events.

According to a twelfth scheduler of the first aspect of the present application there is provided a thirteenth scheduler according to the first aspect of the present application, wherein the current round-robin event enable register is updated with the value of the top ordered round-robin event weight register of the one or more round-robin event weight registers in response to the current round-robin event enable register indicating that one or more round-robin events that may be scheduled are all selected.

According to a thirteenth scheduler of the first aspect of the present application there is provided a fourteenth scheduler according to the first aspect of the present application, wherein one or more round-robin events that can be scheduled in response to a current round-robin event enable register indication are all selected, a second round-robin event weight register is updated with the value of a first round-robin event weight register ordered later in the one or more round-robin event weight registers, the second round-robin event weight register ordered immediately before the first round-robin event weight register.

According to a twelfth scheduler of the first aspect of the present application there is provided a fifteenth scheduler according to the first aspect of the present application, wherein the value of the front-most ordered one of the one or more round-robin event weight registers is updated to the current round-robin event enable register in response to each of the one or more round-robin events that may be scheduled as indicated by the current round-robin event enable register being selected in turn.

According to a fifteenth scheduler of the first aspect of the present application there is provided a sixteenth scheduler of the first aspect of the present application, wherein a second round-robin event weight register is updated with a value of a first round-robin event weight register ordered later of the one or more round-robin event weight registers in response to each of one or more round-robin events schedulable according to the current round-robin event enable register indicating that the round-robin event is to be scheduled.

According to one of the first to sixteenth schedulers of the first aspect of the present application, there is provided a seventeenth scheduler according to the first aspect of the present application, further comprising a priority event selector; the priority event selector is coupled to bits of the pending event register corresponding to one or more priority events; and the priority event selector selects the round-robin event to be scheduled with the highest priority according to the priorities of the one or more priority events.

According to a seventeenth scheduler of the first aspect of the present application, there is provided an eighteenth scheduler according to the first aspect of the present application, further comprising an event arbiter; the event arbiter selects one of the priority event selector and the event selected by the round robin event selector as a scheduled event.

According to an eighteenth scheduler of the first aspect of the present application, there is provided the nineteenth scheduler according to the first aspect of the present application, wherein if the event is selected by the priority event selector, the event arbiter selects the event selected by the priority event selector;

if the priority event selector does not select an event, but the round robin event selector selects an event, the event arbiter selects the event selected by the round robin event selector.

According to one of the first to nineteenth schedulers of the first aspect of the present application, there is provided a twentieth scheduler according to the first aspect of the present application, further comprising a processing function table section; the processing function table component stores the entry addresses of events and their processing functions in association.

According to a twenty-first scheduler of the first aspect of the present application, there is provided a twenty-first scheduler of the first aspect of the present application, wherein the event handling function calling section acquires an entry address of a handling function from the handling function table section according to a scheduled event.

According to one of the first to nineteenth schedulers of the first aspect of the present application, there is provided a twenty-second scheduler according to the first aspect of the present application, wherein the event handling function calling means instructs to acquire an entry address of a handling function of the scheduled event from a message corresponding to the scheduled event.

According to one of the first to twenty-second schedulers of the first aspect of the present application, there is provided a twenty-third scheduler according to the first aspect of the present application, further comprising: enabling an event register and an event status register; each bit of the enable event register is used to indicate whether a corresponding event can be scheduled; each bit of the event status register is used to indicate whether a corresponding event occurs.

According to a twenty-third scheduler of the first aspect of the present application, there is provided a twenty-fourth scheduler according to the first aspect of the present application, wherein each bit of the event register to be processed is set according to a bitwise and result of the enable event register and the event status register.

According to a second aspect of the present application there is provided a method of first sending a message according to the second aspect of the present application, comprising: registering a processing function that sends a message through the queue; indicating a message to be sent; and in response to the processing function being invoked, the processing function sends the message through the queue.

A method of sending a message according to the first aspect of the present application provides a method of sending a message according to the second aspect of the present application, wherein the processing function is instructed to be invoked by any scheduler according to the first aspect of the present application.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are needed in the description of the embodiments will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a block diagram of an embedded multi-core CPU system;

FIG. 2A is a diagram of a task processing system architecture according to an embodiment of the present application;

FIG. 2B is a schematic diagram of scheduling execution of code segments of processing tasks according to an embodiment of the application;

FIG. 3 is a diagram illustrating task scheduling by a task scheduling layer program according to an embodiment of the present application;

FIG. 4 is a flow chart of sending a message according to an embodiment of the application;

FIG. 5 is a flow chart of a received message according to an embodiment of the application;

FIG. 6 is a flow chart of reading data from an external memory according to an embodiment of the application;

FIG. 7 is a flow chart of writing data to an external memory according to an embodiment of the application;

FIG. 8 is a flow chart of using user events according to an embodiment of the present application;

FIG. 9 is a flow chart of reading data from an external nonvolatile memory according to an embodiment of the application;

FIG. 10 is a flow chart of writing data to an external nonvolatile memory according to an embodiment of the present application;

FIG. 11 is a flow chart of processing IO commands to access a storage device in accordance with an embodiment of the present application;

FIG. 12A is a block diagram of a priority weighted round robin scheduler according to an embodiment of the present application;

FIG. 12B is a rotation event weight table according to an embodiment of the application;

FIG. 12C is yet another round robin event weight table according to an embodiment of the present application; and

FIG. 13 is a block diagram of a priority weighted round robin scheduler in accordance with yet another embodiment of the present application;

Detailed Description

The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are some, but not all embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

Example 1

FIG. 2A is a diagram of a task processing system architecture according to an embodiment of the present application.

As shown in fig. 2A, the task processing system includes one or more CPUs and hardware resources (e.g., queues), the CPUs being coupled to a plurality of queues (inbound queue 0, inbound queue 1, outbound queue 0, outbound queue 1) for exchanging messages with external devices. The CPU runs a task scheduling layer program in memory and a program that processes tasks, such as code segments that process tasks.

Multiple tasks may be processed simultaneously on the CPU, in the example shown in FIG. 2A, the CPU includes a code segment for processing task 0 (indicated by "task 0"), a code segment for processing task 1 (indicated by "task 1"), a code segment for processing task 2 (indicated by "task 2"), a code segment for processing task 3 (indicated by "task 3"), and a code segment for processing task 4 (indicated by "task 4"). The plurality of tasks are processed in a sequence that cooperatively implements the functionality of the task processing system (e.g., processes IO commands that access the storage device). A subsequent task may be specified in each task or a different subsequent task responsive to a different event. For example, one of the successor tasks of task 0 is task 2, one of the successor tasks of task 1 is task 0, and the successor task of task 4 is task 3. By way of example, each task implements one phase of IO command processing. In a task processing system, a plurality of IO commands may be processed simultaneously. Accordingly, a Context resource (Context) is provided for each IO command, which may be used by the code segments of the processing task to distinguish between processing of different IO commands.

When run by the CPU, the task scheduling layer program provides an API (application programming interface ) for the code segments that handle the tasks. The code segment that handles the task informs the task scheduling layer program of the hardware (e.g., queue) it is to operate on by calling the API, and the task scheduling layer program examines the hardware state and, when hardware resources are available, operates the hardware to complete the operation requested by the code segment that handles the task through the API. Optionally, the code segment of the processing task also registers other code segments for processing events by calling the API, for example, to fill the outbound queue 1 with a message, and after receiving a response message from the inbound queue 1, to be processed by the code segment of the processing task 2. The task scheduler layer program invokes a code segment that handles task 2 in response to the presence of a message on inbound queue 1.

In an embodiment according to the application, the task scheduling layer program provides a running environment for the code segments handling the tasks through the API, which has the following advantages:

(1) The API provided by the task scheduling layer program is asynchronous, and after the code segment of the processing task calls the API, the called API returns immediately, so that the execution of the code segment of the processing task is not blocked;

(2) The task scheduling layer program processes the hardware operation, and shields the details and the variability of the hardware operation to the code segments for processing the task, so that the code segments for processing the task do not need to pay attention to the availability of hardware resources and/or the delay of hardware processing;

(3) The task scheduling layer program schedules proper code segments according to the state of the hardware resources, and arranges the execution sequence of each code segment so as to balance the delay of task processing and the CPU execution efficiency.

FIG. 2B is a schematic diagram of scheduling execution of code segments of processing tasks according to an embodiment of the application. In fig. 2B, the direction from left to right is the direction of time lapse. Solid arrows indicate the temporal order of task processing, and dashed arrows indicate the logical order of task processing.

For a single CPU, only one piece of code can be processed at any one time. Illustratively, as shown in fig. 2B, for a plurality of code segments to be processed, a code segment of processing task 0 is executed first, a code segment of processing task 1 is executed next, a code segment of processing task 4 is executed next, a code segment of processing task 2 is executed next, a code segment of processing task 0 is executed next, and a code segment of processing task 3 is executed next. While in the code segments of the respective processing tasks a logical order of task processing is indicated, e.g. comprising task 2 to be processed after task 0, task 0 to be processed after task 1, task 3 to be processed after task 4, etc.

The code segments for subsequent processing are registered with an application programming interface provided by the task scheduling layer program by using the task scheduling layer program, so that the code segments for processing the task only need to be appointed for the subsequent code segments according to the logic sequence of the task, and the task scheduling layer program schedules the code segments for processing the task on the CPU under the requirement of meeting the logic sequence.

In the embodiment of the application, the code segments of the processing tasks do not need to check the availability of hardware resources, the sequence among the code segments of the processing tasks does not need to be maintained, the CPU utilization rate is improved, and the complexity of the code segments of the processing tasks is reduced.

FIG. 3 is a diagram of task scheduling by a task scheduling layer program according to an embodiment of the present application.

The hardware resources available to the CPU include a plurality of queues, e.g., inbound and outbound queues (see fig. 1). The hardware resources also include memory, timers, etc. To facilitate the sending of messages by code segments that handle tasks, the task scheduler layer program provides APIs such as a registration (register) API, a send (SendMessage) API, and the like.

In one example, as shown in FIG. 3, when executed by the CPU, the task scheduler layer program maintains a hardware resource status table, which is used to record the status of individual hardware resources. For example, in a hardware resource status table, it is recorded whether each queue is available. For an inbound queue, the queue may mean that pending messages appear in the inbound queue. For an outbound queue, the queue may mean that messages may be added to the outbound queue for transmission to the recipient of the queue. For a timer, timer may mean that the timer expires or that the timer is not counting. For memory, memory availability means that the memory controller is idle, a data write operation is completed to the memory or data is read from the memory.

As shown in fig. 3, the task scheduling layer program also maintains a processing function table that records registered processing functions corresponding to the respective hardware resources when executed by the CPU. In response to the hardware resources being available, invoking a processing function corresponding to the available hardware resources from a processing function table.

Alternatively, the hardware resource status table and the processing function table are integrated in a single table. The state of the hardware resource and the processing function are recorded in the table entry with the hardware resource as an index of the table entry. Still alternatively, only available hardware resources are recorded in the single table, in response to the hardware resources being available, entries corresponding to the available hardware resources are added to the single table, and in response to the hardware resources being unavailable, entries corresponding to the unavailable resources are deleted from the single table, such that the recording of the state of the hardware resources may be omitted.

In yet another example, as shown in FIG. 3, the task scheduler layer program, when run by the CPU, also maintains a context table for recording cached contexts (mContexts).

Optionally, in the processing function table, processing functions corresponding to respective messages to be processed are recorded, and cached contexts (mContext) corresponding to respective messages are recorded in the context table.

As shown in fig. 3, in the CPU initialization phase, a code segment of a processing task registers processing functions that send messages for one or more queues (e.g., processing functions that are registered to outbound queues, or processing functions that are registered to inbound queues, via a registration (Register) API, for example (301). The task scheduling layer program, in response, records the queues and their associated processing functions in a processing function table.

As yet another example, the code segment of the processing task specifies an inbound queue (qID) and a processing function (301) that operates hardware (inbound queue indicated by qID) to receive messages through a registration API (e.g., register (qID, messageInboundCallback)). The task scheduler layer program, in response, records the queue indicated by qID and its associated processing function (messageInboundCallback) in a processing function table.

At step 302, the code segment of the processing task indicates via the send (SendMessage) API that a message (mContext) is to be sent via the queue indicated by qID. The task scheduler layer program, in response, records the queue indicated by qID and its associated context in a context table.

The registration and sending APIs are asynchronous and are not scheduled to block code segments that handle tasks. The registration and send API may be invoked multiple times to register multiple processing functions, or to send multiple messages.

In response to the presence of a pending message in the inbound queue, the task scheduling layer program invokes a processing function (messageInboundCallback) that operates the hardware to receive the message (303).

In response to the presence of a pending message in the outbound queue, the task scheduling layer program invokes a processing function (304) that executes operating hardware to send the message.

In fig. 3, step 301 is associated with step 304, by way of example. Registering a processing function (messageInboundCallback) with an inbound queue indicated by qID with a task scheduler layer program, via step 301; and when the inbound queue indicated by qID has a message pending (step 304), the task scheduling layer program invokes a processing function (messageInboundCallback) registered in association with the inbound queue indicated by qID.

In step 302, no processing function registered in association with the outbound queue indicated by qID is specified. Other calls to the registration API are required to cause the task scheduler layer program to record in the processing function table the processing functions registered in association with the outbound queue indicated by qID. And the associated processing functions are obtained by the task scheduling layer through the processing function table when the outbound queue indicated by qID is available and the messages to be sent on the outbound queue indicated by qID are obtained through the context table. And schedule the processing function to send the message.

The task scheduler layer program loops processing steps 310, 320 and 330.

In step 310, the task scheduling layer program obtains available hardware resources. Illustratively, the available hardware resources (e.g., queues) are obtained by accessing a hardware resource status table. In one example, when a queue is available, the hardware sets a corresponding status register to indicate that the queue is available, with the status register as an entry in the hardware resource status table. In another example, an interrupt is generated when a queue is available, and entries of a hardware resource status table are set in an interrupt handling routine based on the available queue.

Alternatively, if the hardware resource status table indicates that no hardware resources are available, the execution of steps 320 and 330 is ignored, thereby reducing the utilization of the CPU. Still alternatively, in response to the hardware resource status table indicating that no hardware resources are available, the task scheduling layer program temporarily sleeps itself, or sleeps the CPU, to reduce power consumption. And in response to the hardware resources being available, also resuming execution of the task scheduling layer program and/or waking the CPU.

Next, in step 320, the task scheduling layer program obtains processing functions associated with the available hardware resources. And in step 330, a processing function is invoked. As an example, in response to learning that inbound queue 0 is available at step 310, a table of processing functions is accessed at step 320 to obtain a processing function associated with inbound queue 0 and call the processing function. Optionally, the information of the available queues is also provided as a parameter to the processing function.

Still alternatively, the processing function associated with the queue may also require context. For example, a context associated with a queue (e.g., a message to be sent through the queue) may be obtained by accessing a context table and providing the obtained context as a parameter to a processing function associated with the queue.

After the execution of the processing function is completed, the execution of step 330, which calls the processing function, is completed, returns to step 310, and again obtains available hardware resources and processes based on the available hardware resources.

As yet another example, in response to outbound queue 0 being available, the processing function associated with outbound queue 0 is obtained at step 320. Alternatively, if there is no processing function in the processing function table associated with outbound queue 0, then the process of step 320 is complete, the process of step 330 is skipped, and step 310 is returned to again acquire available hardware resources. Still alternatively, the processing function associated with outbound queue 0 needs a context and accessing the context table does not result in a corresponding context, then the process of step 320 is complete, and the process of step 330 is skipped, and the process returns to step 310 to again acquire available hardware resources.

In one example, the processing function uses available hardware resources and makes the available hardware resources unavailable. In yet another example, the processing function does not use hardware resources, which in turn, after the processing function execution is completed, results in the available hardware resources to which the processing function is called remaining available. In another example, the task scheduling layer program uses available hardware resources and provides them to the processing functions such that the available hardware resources will become unavailable regardless of whether the processing functions use the hardware resources. In yet another example, there are multiple copies of hardware resources available, and the task scheduler layer program or processing function uses one copy of the hardware resources available.

The processing functions belong to a code segment of a processing task. The processing functions registered to the one or more queues may be altered in the processing functions by a registration API to the task scheduler or by a send API to indicate to the task scheduler that a message is to be sent out through a specified outbound queue (the outbound queue indicated by qID). The context of the message to be sent is also indicated in the sending API, optionally the processing function is also indicated in the sending API. In response, the task scheduling layer program records the context of the outbound queue and its associated message to be sent in a context table and records the outbound queue and its associated processing function in a processing function table.

Alternatively, the hardware resource may be other types of messaging devices than queues. For example, the messaging appliance may include an outbound messaging appliance for outgoing messages and an inbound messaging appliance for receiving messages. The messaging appliance may include a plurality of slots, each slot may communicate messages independently of the other, and messages communicated between the slots are not sequentially constrained. The allocation of slots is handled by the task scheduling layer. The code segments of the processing task may only instruct the messaging appliance that sent the message.

In one example, the task scheduler layer program invokes a processing function to send a message indicated in the context when there is a slot available on the designated messaging appliance. In another example, the sending API indicates the context in which the message is to be sent, the recipient of the message (rather than the message passing device), and the processing function, and the task scheduler allocates the message passing device and records the allocated message passing device and processing function in a processing function table.

According to the embodiment of fig. 3, the task scheduling layer program and the code segment for processing the task do not need to wait for the completion of the message transfer by the hardware, thereby contributing to the improvement of the CPU utilization.

Example two

Fig. 4 is a flow chart of sending a message according to an embodiment of the application. By way of example, the method of sending messages shown in fig. 4 is used to send messages to other CPUs.

To facilitate the sending of messages by code segments that handle tasks, the task scheduler layer program provides APIs such as a registration (register) API, a send (SendMessage) API, and the like. The processing functions of the event (e.g., the processing functions that operate the hardware to send the message) are registered with the task scheduler layer program through the registration API, and when a specified event occurs (e.g., hardware resources are available), the task scheduler layer program invokes the registered processing functions to perform the process of sending the message. Thus, even if running on different hardware platforms, the differences of the different hardware platforms can be adapted without changing the code segment structure by modifying the processing functions of the events.

As shown in fig. 4, to send a message, the code segment of the processing task specifies an outbound queue (qID) through a registration API (e.g., register (qID, messageOutboundCallback)) and a processing function (messageoutloundcallback) that operates the hardware to send the message at step 410. Correspondingly, in step 401, the task scheduler layer program records the mapping relationship of the hardware resources (e.g., outbound queues indicated by qID) and the processing functions (messageoutloundcallback) in the processing function table. In step 420, when the code segment of the processing task indicates a message (mContext) to be sent on the outbound queue (qID) through the send API (SendMessage (qID, mContext)), the task scheduling layer program invokes a processing function (messageoutloundcallback) associated with the outbound queue (qID). The task scheduling layer program also decides the timing of invoking a processing function (messageOutboundCallback). In step 403, in response to hardware resources being available (e.g., the outbound queue (qID) being not full), the registered processing function is invoked such that when the processing function (messageOutboundcallback) is executed (430), the outbound queue (qID) may be added with a message.

By way of example, in step 410, the registration API (e.g., register (qID, messageOutboundCallback)) does not specify a message to be sent.

When a message needs to be sent, the code segment handling the task indicates to the task scheduler in step 420 that there is a message to send out through the specified outbound queue (the outbound queue indicated by qID) by calling the send API (SendMessage (qID, mContext)), and also indicates the context (mContext) of the message to send (e.g., the message itself to be sent, or the storage address and length of the message).

The task scheduling layer program is invoked in response to the send API, caches the specified outbound queue (qID) and message context (mContext) in the context table, and immediately returns (402), so that the code segment that invokes the processing task of the send API can process subsequent operations without waiting for the message to be actually sent through hardware.

Step 410 and step 420 need not be performed continuously. For example, during an initialization phase, the code segment of the processing task performs step 410, and when a message needs to be sent, step 420. Step 410 has an association with step 420 (indicated by the dashed arrow). In the registration API, processing functions such as an outbound queue (qID) are specified, while messages to be sent on the outbound queue (qID) are specified in the send API, and the task scheduling layer schedules the processing functions specified in the registration API to send messages specified by the send API on the outbound queue (qID).

The task scheduling layer program checks the status of the specified outbound queue (see also step 310 of fig. 3). Hardware resources are available (e.g., the outbound queue is not full) at the specified outbound queue (qID), and a processing function (messageOutboundcallback) registered on the specified outbound queue is invoked (403, 430). Whereas the available hardware resources are directly used in the processing function messageoutbound allback to operate the hardware send message (mContext).

In the above example, the send API (SendMessage (qID, mContext)) does not specify a processing function, and the task scheduling layer program calls a specified processing function (messageoutloundcallback) when a specified queue (qID) is available based on the processing function specified by the Register API (qID, messageOutboundCallback).

Step 420 and step 430 need not be performed continuously, but step 420 indicates that step 430 is to be performed next. After execution of step 420, the task scheduling layer program determines execution timing of step 430 according to the state of the hardware resource. Optionally, a processing function (messageOutboundcallback) is specified when the send API is called, so that a fixed mapping relationship between the outbound queue and the processing function need not be established through the registration API. In addition, the processing functions can be registered by the sending API, so that the mapping relation between the processing functions and the sending API is established for each message sending, and the flexibility of the message sending process is enhanced. It will be appreciated that although the processing functions are described above with a single name, different processing functions may be designated each time a processing function is registered.

Still alternatively, in response to invoking the send API, the task scheduling layer program checks whether the hardware resources used (e.g., indicated by qID) are available. If hardware resources are available, the processing function may be directly called without caching the context. And only when the hardware resources used are not available, the context is cached and returned immediately.

Fig. 5 is a flow chart of a received message according to an embodiment of the application.

To assist in processing the code segments of the task to receive messages, the task scheduler layer program provides an API such as a registration (register) API. The processing functions that operate the hardware to receive messages are registered with the task scheduler layer program via the registration API, and when the hardware indicates that a message is present in the inbound queue, the task scheduler layer program invokes the registered processing functions to perform the process of receiving the message. Thus, even if running on different hardware platforms, the processing functions that operate on the hardware to receive messages can be adapted to the differences of the different hardware platforms without changing the code segment structure.

As shown in fig. 5, to receive a message, the code segment of the processing task specifies an inbound queue (qID) through a registration API (e.g., register (qID, messageInboundCallback)) and a processing function (messageInboundCallback) that operates the hardware to receive the message, at step 510. In response thereto, in step 501, the task scheduler layer program records the mapping of the hardware resources (inbound queues (qID)) to the processing functions (messageinboundcallbacks) in the processing function table. The task scheduler layer program calls a registered processing function (messageInboundCallback) in step 502 in response to the hardware resources (inbound queues (qID)) being available. The processing function (messageInboundCallback) is part of the code segment of the processing task. At step 520, a processing function (messageInboundCallback) is executed.

Alternatively, the message is received by operating hardware by executing a processing function (messageInboundCallback) directly using available hardware resources.

Optionally, the task scheduler layer program is instructed through a registration API (Register ()) about multiple ways of using the processing functions. In one embodiment, in response to a message appearing in the inbound queue (qID), the task scheduling layer program invokes a processing function (messageInboundCallback), and the task scheduling layer program presumes that the processing function (messageInboundCallback) will necessarily process a specified number (e.g., 1) of messages appearing in the inbound queue (qID). And the task scheduler layer program checks whether there are messages still present after the specified number of messages are fetched in the inbound queue (qID) to decide whether to call the processing function (messageInboundCallback) again. In another embodiment, in response to the message appearing in the inbound queue (qID), the task scheduling layer invokes a processing function (messageInboundCallback) and a decision is made by the processing function (messageInboundCallback) as to whether to fetch the message from the inbound queue (qID). If the processing function (messageInboundCallback) does not fetch a message from the inbound queue, the task scheduler will call the processing function (messageInboundCallback) again based on the message still being processed in the inbound queue (qID); if the processing function (messageInboundCallback) takes a message from the inbound queue (qID), the task scheduler checks if there is still a message in the inbound queue (qID) after the message is taken and decides whether to call the processing function (messageInboundCallback) again.

To assist in processing code segments of tasks to access external memory, task scheduling layer programs provide APIs for accessing external memory, including read memory (readMemory) APIs, write memory (writeMemory) APIs, read memory synchronization APIs, write memory synchronization APIs, memory copy APIs, and the like.

The event processing function (e.g., a processing function (memerycallback) that processes data read from the external memory) is registered with the task scheduling layer program through an API for accessing the external memory, and when a specified event (e.g., completion of an external memory operation) occurs, the task scheduling layer program calls the registered processing function to perform a subsequent operation.

Fig. 6 is a flow chart of reading data from an external memory according to an embodiment of the present application.

As shown in fig. 6, at step 610, a code segment of a processing task specifies a source address (src), a destination address (dest), and a processing function (memrycallback) through a read memory API (e.g., readMemory (src, dest, memrycallback)), where the processing function is configured to complete in response to an external memory operation.

Correspondingly, at step 601, the task scheduling layer program is invoked in response to a read memory API (e.g., readMemory (src, dest, memeryCallback)), caches the context of the read memory operation (e.g., the context includes the source address, destination address, data size, specified processing function, etc.), and returns so that the code segment of the processing task may continue to perform other operations.

In step 602, the task scheduler layer program obtains the cached context in response to hardware resources accessing the external memory being available (e.g., memory controller being free, memory queue being free, etc.), reads data from the external memory, and writes the read data to the destination address. Next, the task scheduler layer program calls a specified processing function (memerycallback) as a response to the event (read memory completion). The processing function (memmorycallback) is part of the code segment that processes tasks. Correspondingly, in step 620, a processing function (memerycallback) is executed.

Optionally, the read memory API also specifies the size of the read data. Alternatively, the source address is located in an external memory and the destination address is located in a local memory, such as a CPU.

The read memory API is asynchronous and returns immediately after being called without blocking the CPU's operation. The code of the processing task also specifies a processing function (memmorycall) through the read memory API for performing subsequent processing after the read memory operation is completed (data is written to the destination address).

Optionally, the process of accessing data from a destination address is divided into two phases: a read memory request is issued to the external memory and read data is received from the external memory. There may be a long delay between the two phases. After executing the stage of sending a read memory request to an external memory, the task scheduling layer program caches the context again, acquires the cached context after hardware resources are available (the external memory provides read data), writes the data into a destination address, and calls a designated processing function to shorten the delay.

Alternatively, the read memory API (e.g., readMemory (src, dest)) is not designated for processing functions when called.

The data is read from the memory in order to use the data. According to the embodiment of the application, after the task scheduling layer program reads the data from the memory, a processing function (memerycallback) is called to process the read data, so that a code segment for processing the task does not need to wait or repeatedly inquire whether the data is read from the memory. The extra overhead introduced by the asynchronous memory access mode is eliminated, and the programming complexity of the code segment of the processing task is reduced.

FIG. 7 is a flow chart of writing data to an external memory according to an embodiment of the application.

As shown in fig. 7, at step 710, a code segment of a processing task specifies a source address (src) and a destination address (dest) through a write memory API (e.g., writeMemory (src, dest, memrycallback)). The destination address is located in an external memory and the source address is located in a local memory, e.g. a CPU. Optionally, the write memory API also specifies the size of the write data. The write memory API is asynchronous and returns immediately after being called without blocking the CPU's operation.

The task scheduling layer program is invoked in response to a write memory API (e.g., writeMemory (src, dest, memrycallback)), caches the context of the read memory operation (e.g., the context includes a source address, a destination address, a data size, etc.), and returns (701) so that code that processes the task may continue to perform other operations.

The task scheduling layer program obtains the cached context and writes data to the external memory in response to hardware resources accessing the external memory being available (e.g., memory controller being free, memory queue being free, etc.).

Optionally, the write memory API also specifies a processing function (memerycallback). A processing function (memoryCallback) for performing subsequent processing after the write memory operation is completed (data is written to the destination address).

In response to writing data to memory, the task scheduling layer program invokes a specified processing function (memerycallback) as a response to the event (write memory complete) at step 702. Correspondingly, a processing function (memerycallback) is executed. As one example, a message is sent in a processing function (memerycallback) to another processor to indicate that the other processor can access the data written to memory. Optionally, a function pointer is carried in the message, and the further processor accesses the data written to the memory by calling the function indicated by the function pointer.

Optionally, the process of writing data to the destination address of the external memory is divided into two phases: a write memory request is issued to the external memory and an indication of write completion is received from the external memory. There may be a long delay between the two phases. After the task scheduling layer program executes the stage of sending a write memory request to the external memory, the context is cached again, and after the hardware resource is available (the external memory indicates that the write memory is completed), the cached context is obtained again, and a designated processing function is called to shorten the delay.

Alternatively, the processing function is not specified when a write memory API (e.g., writeMemory (src, dest)) is called. The task scheduling layer program does not call the processing function after finishing the operation of writing into the memory.

Similarly, the code segment of the processing task specifies a source address (src) and a destination address (dest) through a memory Copy (src, dest)) API to Copy the data of the source address to the destination address. Both the source address and the destination address are located in the external memory. The memory copy operation is handled by the task scheduling layer.

Furthermore, in an embodiment according to the present application, an API such as a synchronous read memory API, a synchronous write memory API, or the like is also provided. After the code segment of the processing task calls the synchronous read memory API or the synchronous write memory API, the code segment of the processing task is returned to continue to execute after the task scheduling layer program completes the memory access operation. At this point, the code segments of the processing task may already use the data retrieved from memory.

Fig. 8 is a flowchart of using user events according to an embodiment of the present application.

In an embodiment according to the application, the code segments that handle tasks may register processing functions that respond to user events and trigger conditions that trigger user events with the task scheduling layer program via the application programming interface. For example, the trigger conditions include: the time of the trigger event, and/or the number of trigger events. The task scheduling layer program calls the processing function according to the specified trigger condition. The task scheduler layer program provides a registration (register) API for registering events. As shown in fig. 8, at step 810, the code of the processing task specifies an identifier (eventID) for the event and a processing function (userEventCallback) responsive to the event through a registration API (e.g., register (eventID, userEventCallback)). In response, in step 801, the task scheduling layer program records a mapping relationship of an event (e.g., an identifier (eventID) of the recorded event) and its processing function (userEventCallback).

In one embodiment, the task scheduling layer program also provides a trigger API (e.g., triggerUserEvent (eventID)). In step 820, the code segment that handles the task generates a specified event (indicated by an event identifier (eventID)) by calling a trigger API provided by the task scheduler layer program. Correspondingly, in step 802, the task scheduler layer program caches the context (identifier (EventID) or the like) of the specified event, for example, records the state that the event indicated by the EventID has occurred, and returns so that the code that processes the task can continue to execute.

The task scheduling layer program acquires the event in the generated state through the cached context, and further acquires a registered processing function (userEventCallback) corresponding to the generated event. In response to the task scheduler layer program calling the registered processing function (userEventCallBack) in step 803, the processing function (userEventCallBack) associated with the user event is executed in step 830.

Optionally, the trigger API may also specify conditions for the trigger event. In another embodiment, the condition of the trigger event is explicitly or implicitly in the registration API without using the trigger API. The task scheduling layer program identifies the condition of the trigger event from the cached context, and when the condition is satisfied, the registered processing function is called.

FIG. 9 is a flow chart of reading data from an external Non-Volatile Memory (NVM) according to an embodiment of the present application.

To assist in accessing external NVMs for code segments handling tasks, task scheduling layer programs provide APIs for accessing the NVMs, including read NVM (readNVM), write NVM (writeNVM), set NVM (SetNVM) APIs, and the like.

At step 910, the code segment of the processing task specifies a source address (pba) and a destination address (dest) through a read NVM API (e.g., readNVM (dest, pba, NVMCallback)) to read and store data on the NVM indicated by the source address to a location indicated by the destination address (dest). Optionally, the read NVM API further specifies a size of the read data. The destination address is located in an external memory or in a local memory of the CPU. The read NVM API (read NVM (dest, pba, NVMCallback)) is asynchronous and returns immediately after being called without blocking the CPU's operation. The code of the processing task also specifies a processing function (NVMCallback) through a read NVM API (dest, pba, NVMCallback) for performing subsequent processing after the read NVM operation is completed (i.e., data is read out of NVM).

In step 901, the task scheduling layer program is invoked in response to a read NVM API (dest, pba, NVMCallback), caching the context of the read NVM operation (e.g., the context includes source address, destination address, data size, specified processing function, etc.), and returning so that the code segment of the processing task can continue to perform other operations.

The task scheduler layer program obtains the cached context in response to the availability of the hardware resources accessing the NVM (e.g., media interface controllers are idle, etc., a variety of media interface controllers are provided in chinese patent applications CN201610009789.6, CN201510253428.1, CN201610861793.5, CN201611213755.5, CN201611213754.0, or media interface controllers accessing flash memory, etc., as in the prior art) and sends a request to read data from the source address to the media interface controller. There is a large delay from receiving a request to read data from the media interface controller to outputting the data to the NVM. The task scheduler layer program, after having performed the request to send data read from the NVM to the media interface controller, re-caches the context and, after hardware resources are available (902) that the media interface controller provides data read from the NVM, re-retrieves the cached context and invokes the specified processing function (920) to reduce latency.

Optionally, the processing function is used to send the read data to the host through a DMA operation, or to perform data recovery or error handling when there is an error in the read data.

Alternatively, the read NVM API can specify one or more segments of continuous or discontinuous source and/or destination addresses to obtain data from multiple locations of the NVM.

FIG. 10 is a flow chart of writing data to an external Non-Volatile Memory (NVM) according to an embodiment of the present application.

At step 1010, the code segment of the processing task specifies a source address (src) and a destination address (pba) by a write NVM API (e.g., writeNVM (sec, pba, NVMCallback)) to write data at the source address to a location on the NVM indicated by the destination address. Optionally, the write NVM API also specifies a size of the read data. The source address is located in an external memory or in a local memory of the CPU. The write NVM API is asynchronous and returns immediately after being called without blocking the CPU's operation. The code of the processing task also specifies a processing function (NVMCallback) through the write NVM API for performing subsequent processing after the write NVM operation is complete (i.e. the data is written to the NVM).

In step 1001, the task scheduler layer program is invoked in response to the write NVM API (e.g., writeNVM (sec, pba, NVMCallback)), caching the context of the write NVM operation (e.g., the context includes source address, destination address, data size, specified processing functions, etc.), and returning so that the code segment of the processing task can continue to perform other operations.

The task scheduling layer program obtains the cached context in response to the hardware resources (e.g., media interface controller) accessing the NVM being available, and sends a request to the media interface controller to write data to the NVM. Receiving data to be written from the media interface controller has a large delay from the write operation being completed. The task scheduler layer program, after sending a request to the media interface controller to write data to the NVM, re-caches the context and after hardware resources are available (media interface controller indicates that writing data to the NVM is complete) (1002), re-retrieves the cached context and invokes the designated processing function (NVMCallback) (1020) to reduce latency.

Optionally, the processing function performs error handling when the write operation is in error.

Alternatively, the write NVM API can specify one or more segments of continuous or discontinuous source and/or destination addresses to write data to multiple locations of the NVM.

Similarly, the code segments that handle the task set the specified NVM through a set NVM (SetNVM) API provided by the task scheduler layer program. The task scheduler layer program also provides other APIs for asynchronously operating the NVM.

Example III

In an embodiment according to the application, a plurality of tasks are processed in a sequence that cooperatively implements the functionality of the task processing system (e.g., processing IO commands that access the storage device). To function, it is necessary to send a message multiple times (e.g., via an outbound queue) and receive a message multiple times (e.g., via an inbound queue).

The task scheduling layer program provides various types of processing functions to handle the operations of sending and receiving messages. And by combining the processing functions, various task processing procedures are realized. Different types of processing functions adapt the different stages of the functioning of the task processing system.

For example, to implement the function of processing an IO command, it is necessary to divide it into a plurality of stages and provide different types of functions for each stage. Illustratively, as shown in FIG. 11, it is divided into the following stages: (1) receive an IO command (1115); (2) accessing the NVM chip (1118) in accordance with the IO command; (3) obtaining access results from the NVM chip (1155); (4) indicating that IO command processing is complete (1158); and optionally (5) receiving a reply (1185).

Stage (1) receives a message (1115) indicating an IO command as a start of an IO command processing procedure. Stage (2) allocates resources for the IO command (e.g., identifies the IO command, records IO command processing status), and issues a message to access the storage device (1118). Stage (3) receives a message indicating the storage device access result (1155), and the resources used by the IO command (thereby associating the IO command indicated by the received message with the IO command indicated by the message in step (2)). Stage (4) a message is issued indicating that IO command processing is complete (1158). Optionally, in stage (5), a reply message (1185) is received, wherein the reply message indicates that the message in stage (4) that the IO command processing is complete has been correctly received.

Accordingly, a plurality of classes of processing functions for receiving messages and a plurality of classes of processing functions for transmitting messages are provided. Illustratively, a first type of processing function (Portdriver) is used to receive messages, where no context of the function is included in the received message, for receiving messages at, for example, the initial stage of the function. The second type is a processing function (general Driver) for receiving messages, which includes the context of the function for receiving messages at an intermediate stage of the function, for example. The third class of processing functions (MiniDriver) for receiving messages cannot be used alone, but is an extension of the second class of processing functions for receiving messages and indicates the third class of processing functions for receiving messages in the received messages. The first class is used to issue processing functions for messages, which are used to handle the messaging process (GenericDriver). The second class of processing functions (genericdriver+minidriver) for sending out messages is used for handling the message sending process, and the third class of processing functions for receiving messages is indicated in the messages.

Of course, there may be other types of processing functions for sending or receiving messages. To implement the functionality of the task processing system, one or more of the processing functions are used in combination.

FIG. 11 is a flow chart of processing IO commands to access a storage device in accordance with an embodiment of the present application. The code segments that handle the tasks and the task scheduling layer program run on one of the CPUs of the task processing system (denoted CPU 0).

In response to the inbound queue 11A presenting a message indicating an IO command, the task scheduling layer program invokes a first class of processing functions for receiving messages, step 1110. The first class of processing functions for receiving messages as one of the tasks or part of the task, identifies the content of the IO command by retrieving the message. In one embodiment, the task scheduler layer program retrieves messages from the inbound queues and passes them to a first class of processing functions for receiving the messages. In yet another embodiment, the invoked first class of processing functions for receiving messages obtain messages from an inbound queue. The task scheduling layer program invokes the first class of processing functions for receiving messages only when a message is present in the inbound queue, so that the first class of processing functions for receiving messages does not have to query or wait for the inbound queue to be available.

In response to receiving the IO command (1115), the code segment of the processing task allocates resources for the IO command and accesses the storage device (1118). To access the storage device, a message is sent to the outbound queue 11B to instruct other CPUs or controllers of the task processing system to read/write to the NVM chips of the storage device. Optionally, the code segment of the processing task invokes a send message (sendMessage) API to send messages to the outbound queue. In step 1120, the task scheduling layer program, in response to the send message API being invoked, registers a second class of processing functions for sending messages, the second class of processing functions for sending messages indicating read/write operations to the NVM chip, such that in step 1130, the task scheduling layer program may schedule the second class of processing functions for sending messages according to the outbound queue status such that the outbound queue is already available when the second class of processing functions for sending messages is executed without having to query or wait for the outbound queue to be available. In an alternative embodiment, in response to a send message API being called, the task scheduling layer program directly calls a second class of processing functions for sending messages based on the outbound queue being already available, and omits the process of registering the second class of processing functions for sending messages. In the second class of processing functions for sending messages, the outbound queue is operated to send messages through the outbound queue, and optionally, a third class of processing functions for receiving messages is also indicated in the messages, e.g., pointers to the third class of processing functions for receiving messages are added to the messages.

Other CPUs or controllers of the task processing system read/write the NVM chips and send indications of the read/write results to the CPU (CPU 0) of the code segment running the processing task in FIG. 11 through the inbound queue. In response to the inbound queue 11C being presented with a message indicating the result of reading/writing the NVM chip, the task scheduling layer program invokes a second class of processing functions for receiving messages in step 1140. The second class of processing functions for receiving messages as one of the tasks or part of the task, identifies the result of reading/writing the NVM chip by retrieving the message. Optionally, in the embodiment of fig. 11, the second class of processing functions or task scheduling layer program for receiving messages also invokes a third class of processing functions for receiving messages in step 1150 based on the indication of the message. The third class is for receiving a message as one of the tasks or part of the task for further processing the message, e.g. for recovering data that is in error. By indicating to call a third class of processing functions for receiving messages in the messages, the processing functions can be designated for the messages when the messages are sent out through the outbound queue, and flexibility of message processing is improved.

Optionally, in response to receiving a message indicating a result of reading/writing the NVM chip (1155), the code segment of the processing task issues a message indicating that the IO command processing is complete (1158), informing, for example, the host that the IO command processing is complete. Optionally, the code segment of the processing task is invoked by calling a send (sendMessage) API, and in step 1160, the task scheduling layer program is invoked in response to the send (sendMessage) API, registering a first class of processing functions for sending messages, the first class of processing functions for sending messages being used for sending messages indicating that the IO command processing is complete, such that in step 1170, the task scheduling layer program may schedule the first class of processing functions for sending messages according to the outbound queue status. In a first class of processing functions for sending messages, the outbound queue is operated to send messages through the outbound queue 11D. No indication of the processing function of the third class for receiving messages is included in the outgoing message. And releasing the resources allocated for the IO command as the IO command processing is completed.

Optionally, in response to the message indicating completion of the IO command processing, the IO command issuer may also present a reply message to acknowledge receipt of the message indicating completion of the IO command processing. The reply message is filled into the inbound queue. In response to the inbound queue 11E presenting the reply message, the task scheduling layer invokes another first class of processing functions for receiving messages to retrieve the reply message (1185) at step 1180.

Alternatively, the functionality of the task processing system may include more or fewer stages. Each stage processes a task by sending or receiving messages to or from other CPUs/controllers. The implementation of the function starts with the receipt of a message, the sending of the message occurs in pairs with the receipt of the message in one or more stages in the implementation of the function, the second class of processing functions for receiving the message used when the receipt of the message is registered when the message is sent, and an indication of the third class of processing functions for receiving the message used when the message is received can be added to the outgoing message, so that the second class of processing functions for receiving the message, and optionally the third class of processing functions for receiving the message, are invoked when the message is received. Optionally, a second class of processing functions for receiving messages is registered for one or more inbound queues at initialization, and an indication of a third class of processing functions for receiving messages used at the time of receiving the messages is added to the outgoing messages.

The task scheduling layer program, the various processing functions for receiving messages and the various processing functions for sending messages provide an operating environment or framework for implementing the functions of the task processing system. The code segments implementing the plurality of processing tasks of the function send messages by calling a send (sendMessage) API and register processing functions for receiving messages with a receive queue.

Neither the send (sendMessage) API, the processing function used to send the message, nor the processing function used to receive the message blocks execution of the code segments of the processing task. The send (sendMessage) API is asynchronous and is used to register processing functions for sending messages. And the task scheduling layer program schedules the processing functions for sending messages or the processing functions for receiving messages only when resources are available, according to the state of the outbound/inbound queues, so that execution of the code segments for processing tasks is not blocked.

Processing functions that send/receive messages mask the hardware (e.g., outbound/inbound queues) operational details and differences from the code segments of the processing task; so that the code segments of the processing task do not have to be concerned with the availability of hardware resources and/or the delay of hardware processing. Therefore, the development of the task processing system is simplified, and the task processing system is easy to migrate to other hardware platforms.

Fig. 12A is a block diagram of a priority weighted round robin scheduler according to an embodiment of the present application. Task processing systems typically process a variety of events, such as the occurrence of pending messages in an inbound queue, the waiting of messages to be sent out through an outbound queue, the expiration of a user-defined timer, memory accesses, and the like. The priority weighted round robin scheduler according to the embodiment of fig. 12A schedules a variety of events, assists or replaces the task scheduling layer program (see also fig. 2A-11) according to an embodiment of the present application in selecting events to be processed and invoking code segments for processing tasks for processing.

The various events that are scheduled are divided into two categories: priority events and rotation events. By way of example, events such as the occurrence of pending messages in the inbound queue or the waiting of messages for an event to be sent out through the outbound queue belong to priority events, while user-defined timer-to-time events belong to round robin events. Priority events need to be processed in preference to rotation events. The priority events each have a priority, and priority events having a high priority are processed before priority events having a low priority. Still by way of example, each of the round-robin events is processed in turn when there are no priority events to process. The rotation events each have a weight. The weight indicates how often the rotation event is handled in turn. For example, events with high weights are processed less frequently than events with low weights.

Referring to fig. 12A, the priority weighted round robin scheduler includes an enable event register 1210, an event status register 1220, a pending event register 1230, a priority event selector 1240, a round robin event selector 1250, a current round robin event enable register 1260, a round robin event weight table 1270, an event arbiter 1280, and an event handling function call module 1290. By way of example, the priority weighted round robin scheduler is coupled to the CPU of the task processing system. The CPU may access the enable event register 1210, event status register 1220, pending event register 1230, and/or current round robin event enable register 1260, configure the operating policies of the round robin event selector 1250, current round robin event enable register 1260, and/or event arbiter 1280, update or read a round robin event weight table. The event handling function call module 1290 of the priority weighted round robin scheduler instructs the CPU to call a code segment of a processing task by, for example, setting the CPU's program counter.

Each bit of the enable event register 1210 is used to indicate whether the corresponding event is enabled. An event being enabled refers to allowing processing of the event when the event occurs. If the bit of the event register 1210 indicates that the corresponding event is not enabled, the event is not processed even if the event occurs. The CPU masks one or more events from processing by setting the enable event register 1210.

Each bit of the event status register 1220 is used to indicate whether a corresponding event occurs. For example, a pending message appears in the queue and in response, the event status register 1220 is set with a bit corresponding to the queue. As yet another example, the CPU sets event status register 1220 to indicate that one or more events have occurred.

Each bit of the pending event register 1230 indicates whether the corresponding event has occurred and is enabled. Thus, the priority weighted round robin scheduler processes only events that have occurred and are enabled, and does not process events that have not occurred or that have occurred but are not enabled. For example, each bit of event status register 1220 indicates the result of enabling the AND of event register 1210 with the corresponding bit of event status register 1220.

By way of example, the task processing system processes 40 events, and the enable event register 1210, the event status register 1220, and the pending event register 1230 each include 40 bits, each bit corresponding to 40 events being processed one-to-one.

The priority event selector 1240 is coupled to bits in the pending event register 1230 indicating priority events and outputs an indication of one of the priority events to select the priority event. By way of example, the priority event selector 1240 selects the event with the highest priority based on the valid bit of the pending event register 1230 indicating the priority event (indicating the priority event that has occurred and is enabled) and provides it to the event arbiter 1280.

The toggle event selector 1250 is coupled to a bit in the pending event register 1230 that indicates a toggle event and outputs an indication of one of the toggle events to select the toggle event. For example, the rotation event selector 1250 sequentially processes a plurality of rotation events or sequentially processes a plurality of rotation events at a designated frequency.

According to the embodiment of fig. 12A, the round robin event selector 1250 selects one of the events that have occurred and are enabled by the front round robin event enable register 1260 and provides to the event arbiter 1280, as indicated by the current round robin event enable register 1260. The front wheel event enable register 1260 sets bits corresponding to respective wheel events according to the weight of the wheel event to indicate that the wheel event is enabled. In one example, the round robin events have the same weight and the priority weighted round robin scheduler initializes the current round robin event enable register 1260 to indicate that each round robin event is enabled. Event arbiter 1280 informs current round robin enable register 1260 after selecting one round robin event to be processed. In response, the current rotation event enable register 1260 clears the bit corresponding to the processed rotation event so that the processed rotation event is temporarily no longer processed. Further, in response to the corresponding rotation event of the bits of the current rotation event enable register 1260 being processed, all bits of the current rotation event enable register 1260 are cleared, the current rotation event enable register 1260 is again set to indicate that each rotation event is enabled.

Event arbiter 1280 selects one of the events indicated by priority event arbiter 1240 and round robin event arbiter 1250 for processing. In one example, to prioritize priority events, when both priority event arbiter 1240 and round robin event arbiter 1250 indicate an event to be handled, event arbiter 1280 selects the event indicated by priority event arbiter 1240; the event indicated by the round robin event arbiter 1250 is processed only when the priority event arbiter 1240 does not indicate a pending event and the round robin event arbiter 1250 indicates a pending event. Further, the event arbiter 1280 provides a priority inversion or starvation prevention mechanism, in response to events indicated by the round robin event arbiter 1250 not being processed for a long period of time, while events indicated by the round robin event arbiter 1250 are temporarily processed preferentially over events indicated by the priority event arbiter 1240.

The event arbiter 1280 provides the selected processed event to the event handling function call module 1290, and the event is handled by the event handling function call module 1290 according to the code segment of the processing task to which the event corresponds. For example, the event handling function call module 1290 accesses the handling function table (see fig. 3) to obtain and call the code segment of the handling task corresponding to the event based on the event index provided by the event arbiter 1280. As yet another example, the code segment of a processing task is indicated in the message of the inbound queue, the event handling function call module 1290 indicates the specified field of the message to be processed of the inbound queue as the entry address of the code segment of the processing task and invokes the code segment of the processing task according to the event index provided by the event arbiter 1280. Still alternatively, the message of the inbound queue indicates the provision mechanism of the ingress address of the code segment of the processing task through the specified field, selects whether the ingress address is provided by the processing function table or by the specified field of the message of the inbound queue, and the event handling function call module 1290 sets the specified ingress address to the program counter of the CPU. In yet another example, the event handling function call module 1290 obtains the processing address of the code segment of a processing task from the processing function table and, after the code segment of the processing task is invoked, also obtains the entry address of the code segment of a further processing task from the specified field of the message of the inbound queue and invokes the code segment of the further processing task.

Optionally, the CPU sets the location of the entry address of the code segment of the processing task in the message of the inbound queue (e.g., an offset value relative to the message start address). Still alternatively, the message sender, at a specified location in the message header of the inbound queue, describes whether the message carries an entry address for the code segment of the processing task and the location of the entry address in the message.

As yet another example, the code segment of a processing task is indicated in the message of the outbound queue, the event handling function call module 1290 indicates the specified field of the message to be processed of the outbound queue as the entry address of the code segment of the processing task and invokes the code segment of the processing task according to the event index provided by the event arbiter 1280. Optionally, the CPU sets the location of the entry address of the code segment of the processing task in the message of the outbound queue (e.g., an offset value relative to the message start address). Still alternatively, the message sender, at a specified location in the message header of the outbound queue, describes whether the message carries the ingress address of the code segment of the processing task and the location of the ingress address in the message.

As yet another example, the toggle event weight table component 1270 provides events to the current toggle event enable register 1260 that should be enabled. Fig. 12B and 12C are the rotation event weight tables stored in the rotation event weight table section 1270. Referring to FIG. 12B, there are 3 rotation events (denoted E1, E2, and E3, respectively) to be processed, with rotation event E1 having the lowest weight, rotation event E2 having the next lowest weight, and rotation event E3 having the highest weight. In fig. 12B, the letter "Y" indicates that the event of the corresponding list head is enabled, and the letter "N" indicates that the event of the corresponding list head is disabled. The rotation processes event E1, event E2, and event E3. Event E1 is processed every round, event E2 is processed every 1 round, and event E3 is processed every 2 rounds. The toggle event weight table component 1270 provides one row of fig. 12B to the current toggle event enable register 1260 at a time, after processing one round, the arrow moves to the next row of fig. 12B. In every 1 round of event processing, all 3 round events have the opportunity to get the most processed once; if the corresponding event does not occur when preparing to process the carousel event, it is not processed in the carousel.

By way of example, after initialization, the arrow points to row 1 of the rotation event weight table of FIG. 12B. In this round, row 1 of FIG. 12B is provided to current round robin event enable register 1260 indicating that event E1, event E2 and event E3 are all enabled. By way of example still, pending event register 1230 indicates that event E1 occurred, event E2 did not occur, and event E3 occurred. The toggle event selector 1250 selects one of the events according to whether the event occurs and the event enable state indicated by the current toggle event enable register 1260. For example, since event E1 occurs and is enabled, the round robin event selector 1250 selects event E1 to provide to the event arbiter 1280. After event arbiter 1280 selects event E1 for processing, current round-robin event enable register 1260 is notified of the enable of event E1 so that in the current round, even if event E1 occurs again, round-robin event selector 1250 does not select event E1. Still by way of example, next, since event E2 did not occur, the round robin event selector selects event E3 (which has been enabled) to be provided to event arbiter 1280. Event arbiter 1280, in response to selection of event E3, signals current round robin event enable register 1260 to clear the enable for event E3. And in response to the toggle event selector 1250 making a toggle selection for all 3 events (event E1 and event E3 being processed, and event E2 not being present), the arrow of the toggle event weight table component 1270 moves to the next row (e.g., row 2), providing the row 2 content of fig. 12B to the current event toggle enable register. In row 2 of fig. 12B, only event E1 is enabled and event E2 and event E3 are not enabled, so that each row of fig. 12B is weighted such that event E1 is enabled for each round of processing of a round-robin event, with event E2 being enabled once every 1 round and event E3 being enabled once every 2 rounds. The enabled event is in the current round and if it occurs, it is processed. The enabled event is in the current round and if not, the opportunity to be handled in the current round is lost.

Fig. 12C is yet another example of a rotation event weight table. There are 4 rotation events (denoted E0, E1, E2 and E3, respectively) to be processed. Event E1 has the lowest weight and each round has an opportunity to be processed. Event E2 is weighted low a second time, with the opportunity to be processed every 1 round. Event E3 is weighted a second time high, with the opportunity to be processed every 2 rounds. Event E3 is highest weighted and has the opportunity to be processed every 3 rounds. After initialization, line 1 of FIG. 12C is provided to current round robin event enable register 1260 such that event E0 and event E1 are enabled and event E2 and event E3 are disabled. In one round, if event E0 and event E2 occur, round robin event selector 1250 provides event E0 to event arbiter 1280, event E2 is not processed, and event E1 loses the opportunity to be processed in the present round because it is not enabled. In response to event E0 being processed, the bit corresponding to event E0 in current toggle event enable register 1260 is cleared (to indicate event E0 is disabled). In response to all of the toggle events being checked in the current toggle (although only event E0 is processed), the arrow of the toggle event weight table points to the next row (row 2) and the contents of row 2 are provided to the current toggle event enable register 1260.

If the arrow of the toggle event weight table points to the last row of the table, in the next round, the arrow loops around to row 1 of the table.

Alternatively, the CPU sets a rotation event weight table such as fig. 12B or fig. 12C.

Fig. 13 is a block diagram of a priority weighted round robin scheduler in accordance with yet another embodiment of the present application. The priority weighted round robin scheduler according to the embodiment of fig. 13 schedules a variety of events, assists or replaces the task scheduling layer program (see also fig. 2A-11) according to an embodiment of the present application in selecting events to be processed and invoking code segments for processing tasks for processing.

Similar to the priority weighted round robin scheduler illustrated in fig. 12, the priority weighted round robin scheduler of fig. 13 includes an enable event register 1310, an event status register 1320, a pending event register 1330, a priority event selector 1340, a round robin event selector 1350, a current round robin event enable register 1360, a round robin event weight table 1370, an event arbiter 1380, and an event handling function call module 1390.

The priority weighted round robin scheduler of fig. 13 further includes a processing function table component 1392 coupled to the event processing function call module 1390. Optionally, the event handling function call module 1390 is also coupled to a message storage component 1394 of the inbound queue. Optionally, the event handling function calling module 1390 obtains an entry address of a code segment of a handling task from the handling function table according to an event indicated by the event arbiter, and calls a code segment of a corresponding handling task. Still alternatively, the event handling function call module 1390 accesses the message storage component 1394 of the inbound queue corresponding to the co-event, obtains the entry address of the code segment of the processing task from the message, and calls the code segment of the corresponding processing task, according to the event indicated by the event arbiter (e.g., the event indicates that the inbound queue is pending for the message). For events indicating that there is a message to be sent out through the outbound queue and the outbound queue is not full, the event handling function call module 1390 obtains code segments for processing tasks corresponding to co-events and, optionally, also obtains a message to be sent out and provides the message to the processing tasks. Still alternatively, the message to be sent is queried and/or obtained by the code segment of the processing task.

Optionally, after the code segments of the processing task are invoked, the event handling function invocation module 1390 is temporarily turned off by the shutdown component 1396 to process events in sequence, avoiding that the code segments of the processing task are broken during the processing event. And before the code segments of the processing tasks end, opening the event handling function calling module 1390 to allow the event handling function calling module 1390 to call code segments of other processing tasks.

By way of example, the priority weighted round robin scheduler is coupled to the CPU of the task processing system. The CPU may access the enable event register 1310, the event status register 1320, the pending event register 1330, and/or the current round robin event enable register 1360, configure the operating policies of the round robin event selector 1350, the current round robin event enable register 1360, the round robin event weight table 1370, and/or the event arbiter 1380.

The toggle event selector 1350 is coupled to the pending event register 1330 and outputs an indication of one of the toggle events to select the toggle event. The round robin event selector 1350 selects one of the events that have occurred and are enabled by the front round robin event enable register 1360 according to the indication of the current round robin event enable register 1360 and provides to the event arbiter 1380. Event arbiter 1380 informs current round robin enable register 1360 after a round robin event has been selected for processing. In response, current round robin event enable register 1360 clears the bit corresponding to the round robin event being processed. Further, in response to the round robin event corresponding to the enabled bit of the current round robin event enable register 1360 being processed (or the corresponding event not occurring), the round robin event enable setting component 1372 sets the current round robin event enable register 1360 with the value of the round robin event weight register 1374.

The rotation event weight table 1370 records the weight of each rotation event. By way of example, there are 3 rotation events (denoted E0, E1 and E2, respectively) to be processed. Event E0 is the lowest weighted, and each round has an opportunity to be processed. Event E1 is weighted low a second time, with the opportunity to be processed every 1 round. Event E2 is highest weighted and has the opportunity to be processed every 2 rounds. The weight value of each rotation event in the rotation event weight table 1370 is, for example, 0, 1 and 2 corresponding to the events E0, E1 and E2, respectively. In response to, for example, event E0 being instructed to be processed (or processed completed) by event arbiter 1380, rotation event enable setting component 1372 obtains a weight value (0) corresponding to event E0 from rotation event weight table 1370, and sets event E0 in one of rotation event weight registers 1374, 1376 and 1378 according to the weight value to indicate the timing at which the event is enabled next. In the example of fig. 13, the rotation event has 3 weight values, and the rotation event weight registers having the same number of weight values are correspondingly set. Each toggle event weight register includes a plurality of bits, each bit corresponding to one of the toggle events. By way of example, in response to the weight of the event being processed (E0) being 0, a bit corresponding to event E0 is set in the toggle event weight register 1374; in response to the weight of the processed event E1 being 1, a bit corresponding to the event E1 is set in the toggle event weight register 1376; in response to the weight of the processed event E2 being 2, a bit corresponding to the event E2 is set in the toggle event weight register 1378.

In response to the toggle event selector 1350 making a toggle selection for all 3 events (enabled and events that occur are processed, not enabled, or events that do not occur are not processed), the toggle event enable setting component 1372 sets the toggle event weight register 1374 to the current toggle event enable register 1360, and sets the toggle event weight register 1376 to the toggle event weight register 1374, and sets the toggle event weight register 1378 to the toggle event weight register 1376. And clears the toggle event weight register 1378. Alternatively, the toggle event weight registers 1374, 1376, and 1378 are implemented as shift registers such that the value of the toggle event weight register 1376 is transferred to the toggle event weight register 1374 by shifting, and the value of the toggle event weight register 1378 is transferred to the toggle event weight register 1376 by shifting at the same time.

As yet another example, there are 4 rotation events (denoted E0, E1, E2, and E3, respectively) to be processed. Event E0 is the lowest weighted, and each round has an opportunity to be processed. Event E1 is weighted low a second time, with the opportunity to be processed every 1 round. Event E2 is weighted a second time high, with the opportunity to be processed every 2 rounds. Event E3 is highest weighted and has the opportunity to be processed every 3 rounds. Since the events have 4 weights or the rotation interval of the weight indication has 4, 4 rotation event weight registers (respectively denoted as R0, R1, R2 and R3) are sequentially arranged. The round-robin event enable setting component 1372 sets the round-robin event weight register R0 to the current round-robin event weight register 1360 and sets the round-robin event weight register arranged in front with the value of the round-robin event weight register arranged in rear (e.g., sets register R1 to register R0 and register R2 to register R1) per round of event. During each round of event processing, in response to an event (e.g., E1) being processed or completed, a bit corresponding to the event (E1) in the current round-robin event enable register 1360 is cleared, and a bit corresponding to the weight ordering in the round-robin event weight register (R1) indicating the event (E1) is set according to the weight of the event (E1) indicated by the round-robin event weight table 1370.

As yet another example, there are 4 rotation events (denoted E0, E1, E2, and E3, respectively) to be processed. Event E0 is the lowest weighted, and each round has an opportunity to be processed. Event E1 is weighted low a second time, with the opportunity to be processed every 1 round. Event E2 is weighted a second time high, with the opportunity to be processed every 2 rounds. Event E3 is highest weighted and has the opportunity to be processed every 5 rounds. There are 5 kinds of rotation intervals according to the weight indication, and 5 rotation event weight registers (respectively denoted as R0, R1, R2, R3 and R4) are sequentially arranged. During each round of event processing, in response to an event (e.g., E4) being processed or completed, a bit corresponding to the event (E4) in the current round-robin event enable register 1360 is cleared, and a bit corresponding to the weight ordering in the round-robin event weight register (R4) indicating the event (E4) is set according to the weight of the event (E4) indicated by the round-robin event weight table 1370.

In one embodiment according to the application, the occurrence of pending messages in the inbound queue is defined as priority events, while the user registered events belong to a carousel event. Optionally, upon initialization of the task processing system, the CPU sets the inbound queue and/or user-registered event to event status register 1220 bit correspondence. Further optionally, the CPU also sets a code segment for processing tasks corresponding to the event and its entry address. Processing functions (also referred to as code segments for processing tasks) are registered for one or more events, for example, through a registration (Register) API. In response, the event and its associated processing function are recorded in a processing function table.

Further optionally, the CPU sets the priority of the priority event and/or the weight of the rotation event.

During operation of the task processing system, in response to the occurrence of a pending message in the inbound queue, a corresponding bit of event status register 1220 (see FIG. 12) is set. In response to a user registered event being triggered (e.g., a timer expiring), a corresponding bit of event status register 1220 is set. The priority weighted round robin scheduler schedules a plurality of events, selects one of the plurality of events to occur, and sets a program counter of the CPU to an entry address of a code segment of a processing task corresponding to the selected event. After the selected event is processed, the priority weighted round robin scheduler selects another event to be processed. Therefore, the CPU sets the scheduling strategy for a plurality of events without intervening in the scheduling process, and the load of the CPU is shared.

In yet another embodiment according to the application, the occurrence of a pending message in the inbound queue is defined as a priority event, there is a message waiting to be sent out through the outbound queue and the outbound queue is not full defined as a priority event, and the user registered event belongs to a round robin event. Optionally, upon initialization of the task processing system, the CPU sets the correspondence of inbound queues, outbound queues, and/or user-registered events to the bits of enable event register 1210/event status register 1220. During operation of the task processing system, in response to the occurrence of a pending message in the inbound queue, a corresponding bit of event status register 1220 (see FIG. 12A) is set; the corresponding bit of the enable event register 1210 is set in response to the outbound queue not being full, the corresponding bit of the event status register 1220 is set in response to a message waiting to be sent through the outbound queue, and the corresponding bit of the event status register 1220 is set in response to a user-registered event being triggered (e.g., a timer expires or the user-registered event being processed to completion). The priority weighted round robin scheduler schedules a plurality of events, selects one of the plurality of events to occur, and sets a program counter of the CPU to an entry address of a code segment of a processing task corresponding to the selected event.

The foregoing is merely illustrative of the present invention, and the present invention is not limited thereto, and any person skilled in the art will readily recognize that variations or substitutions are within the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A scheduler, comprising: a pending event register, a round robin event selector and a current round robin event enable register;

the pending event register indicates one or more events to be scheduled;

the toggle event selector is coupled to bits of the pending event register corresponding to one or more toggle events and to the current toggle event enable register;

the current round robin event enable register indicates one or more round robin events that may be scheduled; and the rotation event selector selects one of the rotation events to be scheduled according to the indication of the current rotation event enable register;

the scheduler further comprises a round robin event weight table component;

the rotation event weight table section records a plurality of values in order; and to update the current rotation event enable register, sequentially retrieving values from the rotation event weight table section, and updating the current rotation event enable register with the retrieved values.

2. The scheduler of claim 1, further comprising an event handling function call component; the event handling function invoking component invokes a handling function to handle the scheduled rotation event in accordance with the rotation event selector indication.

3. The scheduler of claim 1 or 2, wherein the current round robin event enable register is updated in response to one or more round robin events indicated by the current round robin event enable register that may be scheduled being selected.

4. The scheduler of claim 1, wherein the rotation event selector alternately selects rotation events to be scheduled and that can be scheduled according to the indication of the current rotation event enable register.

5. The scheduler of claim 4, wherein the current round robin event enable register is updated in response to each of the one or more round robin events that may be scheduled as indicated by the current round robin event enable register being selected in turn for which a round robin event is to be scheduled.

6. The scheduler of claim 1, wherein the value recorded by the rotation event weight table component indicates whether one or more rotation events can be scheduled.

7. The scheduler of claim 6, wherein a first round robin event is indicated to be schedulable in a first number of values recorded by the round robin event weight table assembly; a second round robin event is indicated as being schedulable in a second number of values recorded by the round robin event weight table assembly; and the first number is greater than the second number.

8. A scheduler according to claim 3, further comprising a round robin event weight table component; the rotation event weight table component records weights for one or more rotation events.

9. The scheduler of claim 8, further comprising a round robin event enable setting component and one or more round robin event weight registers; the rotation event enable setting section is processed in response to a first rotation event, selects one of the one or more rotation event weight registers to record that the first rotation event is enabled according to the weight of the first rotation event acquired from the rotation event weight table section.

10. The scheduler of claim 9, wherein the one or more rotation event weight registers are ordered, one of the one or more rotation event weight registers being selected according to an ordering of weights of the first rotation event acquired from the rotation event weight table component in a set of weights of rotation events.

11. The scheduler of claim 10, wherein a current round robin event enable register is updated with a value of a top ordered round robin event weight register of the one or more round robin event weight registers in response to the current round robin event enable register indicating that one or more round robin events that may be scheduled are all selected.

12. The scheduler of claim 11, wherein one or more round-robin events that can be scheduled in response to a current round-robin event enable register indicating are all selected, a second round-robin event weight register is updated with a value of a first round-robin event weight register ordered later in the one or more round-robin event weight registers, the second round-robin event weight register ordered immediately before the first round-robin event weight register.

13. The scheduler of claim 11, wherein the current round-robin event enable register is updated with a value of a top-ranked one of the one or more round-robin event weight registers in response to each of the one or more round-robin events that may be scheduled being selected in turn as indicated by the current round-robin event enable register.

14. The scheduler of claim 13, wherein a second round-robin event weight register is updated with a value of a first round-robin event weight register ordered later of the one or more round-robin event weight registers in response to each of one or more round-robin events schedulable according to a current round-robin event enable register indication, the second round-robin event weight register ordered immediately before the first round-robin event weight register.

15. The scheduler of claim 1, further comprising a priority event selector; the priority event selector is coupled to bits of the pending event register corresponding to one or more priority events; and the priority event selector selects the round-robin event to be scheduled with the highest priority according to the priorities of the one or more priority events.

16. The scheduler of claim 15, further comprising an event arbiter; the event arbiter selects one of the priority event selector and the event selected by the round robin event selector as a scheduled event;

if the event is selected by the priority event selector, the event arbiter selects the event selected by the priority event selector;

17. The scheduler of any of claims 4-16, further comprising a processing function table component; the processing function table component stores the entry addresses of events and their processing functions in association.

18. The scheduler of claim 17, further comprising an event handling function calling component that calls a handling function to handle a scheduled rotation event in accordance with the rotation event selector indication;

Wherein the event handling function calling part obtains the entry address of the handling function from the handling function table part according to the scheduled event.

19. A scheduler according to any of claims 4-16, further comprising an event handling function calling component that calls a handling function to handle a scheduled rotation event in accordance with the rotation event selector indication;

the event handling function calling means instructs to acquire an entry address of a handling function of the scheduled event from a message corresponding to the scheduled event.

20. The scheduler of any of claims 1-2 or 4-16, further comprising: enabling an event register and an event status register; each bit of the enable event register is used to indicate whether a corresponding event can be scheduled; each bit of the event status register is used for indicating whether a corresponding event occurs; setting each bit of the event register to be processed according to the bitwise and result of the enabling event register and the event state register.

21. A method of sending a message for use in a scheduler according to any of claims 1-20, the method comprising:

Registering a processing function that sends a message through the queue;

indicating a message to be sent;

and in response to the processing function being invoked, the processing function sends the message through the queue.