JP2003271404A - Multiprocessor system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a multiprocessor system for measuring a use ratio of a CPU, suppressing the use ratio of the CPU to dispersion of a fixed range by performing a dynamic task arrangement and efficiently performing load distribution. <P>SOLUTION: This system has a task mapping table for setting which tasks are arranged in a plurality of CPUs and a timer having a timer value specific to each of the plurality of CPUs. The CPU to which the timer having earlier time-out belongs is made a host, and tasks for the plurality of CPUs are rearranged according to states of the tasks set to the task mapping table. <P>COPYRIGHT: (C)2003,JPO

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a multiprocessor system capable of dynamically allocating tasks to a plurality of CPUs.

[0002]

2. Description of the Related Art Load distribution and function distribution can be mentioned as a structure for realizing a multiprocessor system in which a task is executed by a plurality of CPUs. That is, in the conventional multiprocessor system, all the functions are mounted in common to all the CPUs, and the load of processing by the operable CPUs is distributed, and the function of each CPU is distributed to the predetermined functions. There is a method.

In the latter multiprocessor system by function distribution, since the functions to be mounted can be limited, the processing execution speed can be increased. However, it has a feature that it is vulnerable to obstacles because its functions are integrated.

On the other hand, in the load balancing type multiprocessor system, since the same function is multiplexed, the system is resistant to troubles, but the scheduling of processing is required, and the software configuration becomes complicated. In addition, the processing overhead increases and the processing execution speed decreases. Further, since the processes are distributed to the CPUs in order, the load factor of the CPUs varies depending on the complexity of the processes, and there is a problem that the efficient process distribution cannot be performed.

[0005]

SUMMARY OF THE INVENTION Therefore, an object of the present invention is to measure the CPU usage rate and perform dynamic task placement, whereby the CPU usage rate can be suppressed within a certain range, which is efficient. It is to provide a multiprocessor system capable of load distribution.

Further, an object of the present invention is to suppress inter-processor communication by performing function division in task units,
Accordingly, it is an object of the present invention to provide a multiprocessor system in which the software configuration is easy and the processing overhead can be reduced.

Another object of the present invention is to separate the task running in the faulty CPU at the time of the fault from another CP.
Dynamically relocated to U, enabling continuous processing with another CPU,
This is to provide a multiprocessor system that can minimize the influence of a CPU failure.

Further, the CPU itself for relocating the task is also changed to prevent the load redistribution of the task relocation and the interruption of the relocation function due to the failure of the CPU for relocating the load.

[0009]

According to a first aspect of the present invention, there is provided a multiprocessor system in which a plurality of CPUs execute a plurality of tasks.
Common to each U, the task mapping table indicating the allocation state of the plurality of tasks to the plurality of CPUs, and the task reconfiguration for the plurality of CPUs based on the task allocation state set in the task mapping table. It is characterized in that a means for switching the host CPU to be arranged among the plurality of CPUs is provided.

A second aspect of the multiprocessor system according to the present invention for achieving the above object is, in a multiprocessor system for executing a plurality of tasks by a plurality of CPUs, a task allocation state of each of the plurality of CPUs. Table, a task allocation state set in the table, and a means for rearranging tasks to the plurality of CPUs based on the usage rate of each CPU.

A multiprocessor system according to the present invention for attaining the above object is, as a third mode, a first mode.
In the above aspect, each of the plurality of CPUs further includes an externally provided function list in which a task name and a function name are set, and an external device that accesses a shared memory based on the task mapping table and the externally provided function list. When determining which CPU the provided function object exists in, and when the object exists in another CPU,
It is characterized in that a function call is sent to the other CPU by inter-CPU communication.

A multiprocessor system according to the present invention for attaining the above object is, as a fourth mode, a first mode.
In the above aspect, each of the plurality of CPUs further includes an operation queue and a standby queue in the switching source task and the switching destination task, and when a task switching event occurs, processing in the operation queue of the switching source task is performed. An end (END) event is set after the desired event, an event to be continued is set in the operation queue of the switching destination task, and a switching request message is sent to the standby queue of the switching destination task after the end (END) event is processed. By this, overtaking control at the time of task switching is performed.

A multiprocessor system according to the present invention for attaining the above object is, as a fifth mode, a first mode.
In this aspect, each of the plurality of CPUs has its own CPU memory access area and another CPU memory access area provided in the local memory, and when one CPU fails, the one CPU's own It is characterized in that the CPU memory access area and the other CPU memory access area of the switching destination CPU are connected by bus switching to take over the information of the local memory.

Further, in a multiprocessor system according to the present invention for achieving the above object, as a sixth aspect, in the first aspect, the utilization rate of at least one CPU in the plurality of CPUs is set to another CPU. It is characterized in that the CPU is set to a low value, and when one of the other CPUs fails, the one CPU is set as a recovery destination CPU.

A multiprocessor system according to the present invention for attaining the above object is, as a seventh mode, a first mode.
In this mode, the usage rate in the other CPU is obtained by an inquiry from the CPU serving as the host to the other CPU.

The features of the present invention will be apparent from the embodiments of the invention described with reference to the drawings.

[0017]

BEST MODE FOR CARRYING OUT THE INVENTION Here, prior to the description of the embodiments of the present invention, the outline of the present invention will be described for easy understanding.

FIG. 1 is a diagram showing a configuration example of a multiprocessor system to which the present invention is applied. Multiple CPU1
It has a CPUn, has the same configuration, and is configured to execute application software on an OS (operating system), and further has middleware as an intermediate between the OS and the application software.

FIG. 2 is a diagram showing a configuration example of one CPU of the multiprocessor system shown in FIG. The middleware constitutes an agent 1, a function list table 2 and a task mapping table 3 which will be described later. Further, a plurality of tasks 1 to n are realized by application software.

In the multiprocessor system according to the present invention, in the configuration shown in FIG.
The same load module is loaded for n, and all tasks are uniformly generated.

Further, by dynamically switching the message transmission destination CPU, the task operating on a CPU basis is changed. Therefore, when sending a message, it is necessary to know the CPU on which the target task is operating.

In the multiprocessor system of the present invention,
The task operation information is managed using the task mapping table 3 described above. This makes it possible to determine the CPU on which the target task is operating.

An example of the task mapping table is shown in Table 1 below.

[0024]

[Table 1] The task mapping table 3 shown in Table 1 is a queue identifier (Qid) for identifying a message queue, and a Qid.
To identify the task name to which is assigned, the CPU number on which the task is running, the real address of the message queue (msgQid) on the running CPU, the idle task that cannot be relocated, and the WDT (watchdog timer) monitoring task Of the relocation availability flag.

The message queue has an operation queue and a standby queue, and the normal operation uses the operation queue. The wait queue is a temporary area used for queuing events during task relocation.

Further, when writing data to a shared memory (not shown), there is a possibility that the task of executing data processing and the task of accessing data to the shared memory are operating in different CPUs. In that case, the data to be originally written is only in the local area of the task that executed the data processing, and if the task that accesses the shared memory is operating in another CPU, the expected data is written in the shared memory. There will be no.

Therefore, when accessing the shared memory, it is necessary to notify the data from the task that executes the data processing to the task that accesses the shared memory. Therefore, the multiprocessor system according to the present invention is provided with a processing unit that controls the message transmission function and the shared memory access function. Here, for the sake of convenience, the functional unit is named "agent" and has the configuration of the agent 1 shown in FIG.

In the configuration shown in FIG. 2, the functions provided by the "agent" according to the present invention will be described below. [Shared memory access function] 1-1. Agent 1
When the "processing determination unit" receives a function call for accessing the shared memory (refers to the agent of the first CPU), the corresponding function is referenced by referring to the externally provided function list of the function list table 2 and the task mapping table 3. Which CP
Determine if it is assigned to U.

1-2. If the corresponding function is assigned to the own CPU, the function is called as it is. In the case of another CPU, the general message queue ID is acquired by the “message queue management unit”, and the CPU 2 communicates with the agent 2 of the destination CPU by the “message transmission unit”.

2-1. Agent 2 that received the message from Agent 1 in the "message receiver"
(Indicates the second CPU agent) is the externally provided function INDEX in the message received by the "processing determination unit".
Based on the number, the processing function is obtained by referring to the externally provided function list table 2 and the mapping table 3, and the function call is made to the target function.

Here, the above-mentioned externally provided function means that the processing request source task requests the processing request destination task to perform processing by a function call, the actual processing is executed by the request destination task, and the request source task executes the result. Just say if you get.

2-2. When the agent 2 receives the processing result from the shared memory access function in the “processing determination unit”, the “message transmission unit” performs inter-CPU communication with the general-purpose queue notified from the agent 1 and returns the processing result.

1-3. When the agent 1 receives the processing result at the "message receiving unit", the agent 1 returns the processing result to the activation source task and releases the general-purpose queue. [Message Transmission / Reception Function] 1-1. Agent 1
When the “process determination unit” receives a message transmission request from task A to task B, task mapping table 3
To check which CPU the relevant task is located.

1-2. If the destination task B is located in its own CPU, the agent 1 performs inter-task communication with the task B by the "message sending unit", but if it is located in another CPU, the "message sending unit".
Then, the inter-CPU communication is performed with respect to the agent 2 in the target CPU.

2-1. At the agent 2 that received the message from the agent 1 at the “message receiving unit”, the message received at the “processing determination unit” is the own CP.
Whether or not it is addressed to the task in U is confirmed by referring to the task mapping table 3, and inter-task communication is performed for the relevant task. [Task running time calculation function] The "task running time management unit" calculates each task running time in its own CPU and manages the task running time management table in the "task running time management unit". [Dynamic switching function of task allocation] When the "timer management unit" detects the time-out of the started periodic timer, the agent operates as a host CPU, and the "message transmission unit" uses the inter-CPU communication to transfer to another CPU. A CPU usage rate report request is sent to it.

The agent which has received the CPU usage rate report request from the "message receiving unit" sends the task running time management table information to the CPU from the "message transmitting unit".
It is sent to the requesting agent as a usage report message.

Further, the agent (host) which has received the CPU usage rate report in the "message receiving unit" calculates the variation in the task placement based on the running time of each task in the "task placement switching unit", The mapping table 3 is updated. The updated task mapping table 3 is stored in the "message sending unit" from each CP.
Send to U agent using inter-CPU communication.

The agent that received the updated task mapping table uses the "task placement switching unit" to execute the CP.
The task placement is switched while performing the overtaking control at the time of U switching. [Fault Recovery Function] In the present invention, since the CPU can be dynamically switched, the CPU usage rate is 100 even if the CPU of the faulty device takes over the process in preparation for the CPU fault.
Place a CPU with low usage rate so that it does not exceed%,
The "failure recovery unit" implements recovery processing for a CPU failure. This makes it possible to achieve high resistance to system failures.

Here, each of the CPU1 to CPUn is C
It holds a different timer value for each CPU obtained by calculation from the PU number and the like (hereinafter, referred to as an individual timer). In the timer management unit of the agent 1 shown in FIG. 2, an individual timer held by each CPU is set when the system is restarted.

After the individual timer times out, a different periodic timer is set for each CPU. The CPU that first detects the timeout of the individual / periodic timer set in the timer management unit is the host CPU. Therefore, in the present invention,
Any of the CPUs can operate as a host CPU and can dynamically switch the host CPU.

For each of the CPU1 to CPUn, the above table 1
The task mapping table 3 shown in FIG. 2 is held, and the task allocation switching unit of the agent 1 existing in each CPU shown in FIG. 2 dynamically reallocates the task based on the CPU usage rate.

By using the task mapping table 3 shown in Table 1, the processing determination unit, the message queue management unit, the message transmission unit, and the message reception unit of the agent 1 shown in FIG. Send and receive messages.

Further, by using the task mapping table 3 and the externally provided function list shown in Table 1, a shared memory is stored in the processing determination unit, the message queue management unit, the message transmission unit, and the message reception unit of the agent 1 shown in FIG. It is possible to perform the function call without being aware of which CPU the object of the externally provided function to access exists.

Specific processing to be realized will be sequentially described below in relation to each functional unit provided in the above agent. [Task Relocation] An example of the task relocation according to the present invention described above will be described with reference to the task relocation sequence shown in FIG. S1: In the present invention, when the system is restarted (processing step P1), each timer calculates an individual timer value obtained from the serial number of the CPU or the like in each CPU. S2: This individual timer value is set, and the timer value is individually set.

The individual timer values are, for example, CPU1 to CPU1.
PU3 is set to 1 second, 2 seconds, and 3 seconds in this order. S3: When the individual timer times out first (process step P2), the CPU that times out first becomes the host CP.
Act as U. S4: Since the individual timer of the CPU 1 times out first, the agent 1 of the CPU 1 sends a CPU usage rate report request to the other CPUs 2 and 3 by using the CPU 1 as a host CPU (FIG. 3: S4). ). S5: The agent 1 of the CPUs 2 and 3 which has received the CPU usage rate report request stops the individual timer. S6: CPU usage rate measured from CPUs 2 and 3 is C
It reports to the host CPU by communication between PUs. When the system is restarted, the CPU usage rate is reported as 0%. S7: Host CP that received the CPU usage report message
The U agent 1 determines whether the system is restarted or the CPU is reset based on the CPU usage rate. When the system is restarted, all the CPUs report a CPU usage rate of 0%, so the task mapping table 3 uses the default task mapping table.

When the CPU reset is restarted, the CPU usage rate is reported at a value other than 0%. Therefore, the task mapping table 3 and the CPU notified by the CPU usage rate report message are reported.
Using the usage rate, it is determined whether or not there is a variation in the CPU load rate, and the task mapping table is created / updated (processing step P3). However, CPUs whose CPU usage rate has been intentionally reduced in case of a CPU failure are excluded.

When the agent 1 of the host CPU updates the task mapping table 3, the agent 1 of the host CPU sends a task mapping table update notification to the other CPUs by using inter-CPU communication.

As a result, the agents 1 of all CPUs that have received the task mapping table update notification are
The task mapping table 3 in the PU is updated, and the task allocation shown in the task mapping table 3 is switched. S8: Here, all the CPUs start a timer with a periodic timer (= reference timer value + individual timer value) that the system has in common. However, the reference timer value is the same for each CPU and is a sufficiently large timer value with respect to the individual timer value.

After that, when the cycle timer times out, the above steps S1 to S7 are similarly repeated, the task mapping table is updated, and the dynamic task relocation is performed.
Therefore, as shown in FIG. 4, it is possible to dynamically switch the tasks operating on the CPU and dynamically balance the CPU load (uniformize the usage rate).

That is, referring to FIG. 4, the CPU utilization rate of the task allocation by default mapping is 20% for task A for CPU 1 and task B for task A as an example.
20% for CPU2, 10 for task C2
%, 5% for task D, 5% for task E for CPU3, and 0% for task F.

From the state of this default mapping, FIG.
As a result of performing the process of dynamically allocating the task from the CPU usage rate by the procedure shown in, the CPU 1 has 20% of the task A and the CPU 2 has 2 of the task B.
0%, 10% for task C for CPU3, 5% for task D, 5% for task E, and 0% for task F. Therefore, CPU1, CPU2,
The CPU 3 has a usage rate of 20%, which makes the usage rate uniform.

Immediately after the initial startup as described above, the utilization ratio varies among the CPUs due to the default mapping arrangement (FIG. 4A). However, the host CPU may change the mapping by reporting the CPU utilization ratio. Is made uniform as shown in FIG. 4B. [Message Transmission] In the present invention, when a message is further transmitted, the agent 1 refers to the task mapping table 3 shown in Table 1 shown above, determines the CPU in which the task is operating, and transmits the message. Determine the communication method to perform.

When the destination task is operating on the same CPU as the source task, the agent uses the inter-task communication to send messages, but when operating on another CPU, the inter-CPU communication is used. And send a message.

As described above, the agent is the CP
It exists for each U, and each task requests the agent 1 to send a message, so that the message can be sent without being aware of the CPU to which it belongs.

FIG. 5 shows an outline of such message transmission scheduling. In FIG. 5, consider the case where a message is sent from task A of CPU1 to task B of CPU2. SS1: Task A requests agent 1 to send a message to task B without being aware of the operating CPU. SS2: The agent 1 refers to the task mapping table 3 and determines whether the task A and the task B are operating in the same CPU. SS2-1: When the task A and the task B are operating in the same CPU, the agent 1 uses the intertask communication to send a message to the corresponding task B. SS2-2: On the other hand, task A and task B are other CPU2
, The agent 1 uses the inter-CPU communication to send a message to the agent 2 of the CPU 2. SS3: The agent 2, which has received the message, transfers the message to the corresponding task. Therefore, message transmission can be scheduled without being aware of the multiprocessor. [Externally Provided Function] Here, when performing shared memory access, there is a possibility that the task of performing data processing and the task of accessing data to the shared memory are operating in different CPUs.

In this case, the data to be originally written is only in the local area of the task that executed the data processing, and when the task that accesses the shared memory is operating in another CPU, the expected data is written in the shared memory. There will be no.

Therefore, when accessing the shared memory, it is necessary to notify the task of executing the data processing to the task of accessing the shared memory of the data.

The agent refers to the task mapping table 3 and the externally provided function list table 2 to specify the CPU in which the object of the externally provided function that accesses the shared memory exists, and the externally provided function object is the C
If it exists in PU, a direct function call is made.

However, if it exists in another CPU, CP
Using U communication, another CPU agent is requested to perform processing, and another CPU agent makes a function call. Other C
When the process is executed in the PU and the process is completed, another CPU
The agent notifies the processing result.

When requesting a process to another CPU agent, a temporary message queue that is taken for each process request to another CPU agent is used. This message queue is called a general-purpose queue.

However, since the message reception cannot be used from within the handler, the externally provided function cannot be used.

FIG. 6 is a diagram showing an embodiment in which an externally provided function call is made between processors.

When the function call is activated from the task A (FIG. 6: S51), the agent 1 of the CPU 1 refers to the externally provided function list table 2 and the task mapping table 3 to access the externally provided function. The CPU in which the object is present is specified.

If the externally provided function object exists in its own CPU 1, the agent 1 processes the direct function call. However, when it exists in the other CPU 2, the inter-CPU communication is used to request the agent 2 of the other CPU 2 for processing (FIG. 6: S62).

From agent 2 of other CPU 2 to task B
A function call is made to the externally provided function object (FIG. 6: S63). When the processing is executed by the other CPU 2 and the processing is completed, the processing result of the other CPU agent 2 is passed (FIG. 6: S64), and the processing result is notified by the inter-CPU communication (FIG. 6: S65).

As a result, the processing result is passed to the task A by the agent of the CPU 1 (FIG. 6: S66).

When requesting the processing to the other CPU agent 2, the above-mentioned temporary general-purpose queue that is taken every processing request to the other CPU agent 2 is used.

In the multiprocessor system according to the present invention, a combination of a task and an externally provided function for accessing table information managed by the task is referred to as a function block (FB).

In advance, all CPUs hold an externally provided function list table 2 as shown in the following Table 2 owned by each functional block FB.

[0070]

[Table 2] The externally provided function list table 2 has an INDEX number, F
B name, name of externally provided function for actual processing, name of agent function used in agent, general queue identifier (general QI
It consists of D).

The externally provided function list is INDEX for each function.
Are assigned and can be accessed by the INDEX number. The externally provided function is provided by the agent function name, and the agent providing the externally provided function calls the actual processing externally provided function.

Therefore, the task may always make a function call to the agent in its own CPU with the agent function name, and the externally provided function can be used without being aware of the CPU in which the externally provided function exists. . [Scheduling of Externally-Provided Function] Next, FIG. 7 shows the details of the scheduling method of the externally-provided function for accessing the shared memory. S11: The externally provided function is called by the task A on the CPU 1. S12: In the agent 1, the function list table 2 is defined as the function block FB to which the externally-provided function called belongs.
Refer to to specify. That is, the function list table 2
It is confirmed by referring to which function block FB the target externally provided function belongs. S16: 3 Agent 1 then determines a function call method. S14: The agent 1 directly calls the function if the externally provided function is in its own CPU, but if it is another CPU, the CPU
Function calls are indirectly made using inter-communication. In order to communicate between CPUs, a general-purpose message queue ID is acquired, and the CPU
Create an inter-interface. S15: The agent 1 acquires a general-purpose Qid so that the function call source can be identified, and the general-purpose Qid is stored in the inter-CPU IF.
The argument information and the INDEX number are stored and the message is transmitted using the inter-CPU communication. S16: When the message is received, the agent 2 refers to the function list 2 to search for a function to call. Then, a function call is made to the actual processing externally provided function designated by the INDEX number of the inter-CPU IF. S17: Processing is executed in the actual processing externally provided function. S18: The agent 2 of the CPU 2 receives this processing result. S19, S20: Then, the agent 2 stores the processing result and the general-purpose Qid in the message of the inter-CPU communication,
Send a message. S21, S22, S23: The agent 1 of the CPU 1, which has received the processing result through the inter-CPU communication, sends a message to the general-purpose queue, sends the processing result to the calling task A by inter-task communication, and sends the general-purpose Qid. release.

As described above, the task mapping table 3
And the function list of the function list table 2 are used to determine in which CPU the object of the externally provided function that accesses the shared memory exists. Then, an externally provided function for accessing the shared memory can be used by using an agent for mediating communication between CPUs and function call. [Task switching control] Here, in the above-mentioned task relocation, when tasks are relocated across different CPUs, consistency in the event processing order cannot be maintained without overtaking control. .

In FIG. 8 showing the overtaking control image, for example, in the state where events 1 to 3 are waiting for processing (FIG. 8A: CPU1), when the task relocation from CPU1 to CPU2 is performed, the switching source In the CPU1, the switching destination CPU2 after executing the events 1 to 3
It is necessary to execute events 4 to 5. This waiting process is called overtaking control.

FIG. 9 shows the procedure of overtaking control when task switching occurs between CPUs in connection with FIG.

In FIG. 9, the task switching source is the CPU 1,
The task switching destination is CPU2. Each task has an operation queue for accumulating normal events and a standby queue dedicated to a switching request message that notifies the task switching timing. The CPU 1 performs the following procedure. (1-1) :, updated task mapping table 3
To receive. (1-2): The agent of the CPU 1 that manages the task puts the END event informing the switching target task A of the CPU 1 that the incoming event is the last in the operation queue. (1-3): For other events to the switching target task A, the task mapping table 3 is updated (1-
Therefore, after that, the data is accumulated in the operation queue of the CPU 2. That is, a reception event from another CPU is forwarded by the agent. (1-4): The CPU 1 processes the event accumulated in the operation queue, detects the END event, and then notifies the agent of a switching request event for notifying the task itself (the switching destination CPU 2) of the switching destination of the task switching. To send. Note that management information (all tables) is attached to the switching request event. (1-5): The switching target task A starts waiting by the waiting queue and cancels waiting in the operation queue. In the CPU 2, the procedure process is next performed. (2-1): Receive the updated task mapping table 3. (2-2): When the event message is received, the CPU
The second agent accumulates the event in the operation queue. (2-3): The agent accumulates the switching request event from the CPU 1 in the standby queue. (2-4): The switching destination task processes the message accumulated in the operation queue upon execution of the switching request event.

According to the above-mentioned switching processing procedure, the task A in the CPU 1 waits for execution of the events 1 to 3 in the CP state.
When the mapping is changed to U2, the agent generates the END event after the event 3 in the CPU 1 (FIG. 8B: P10).

Since the CPU 1 executes the events up to the END event process, the events 1 to 3 are executed by the CPU 1 (FIG. 8B: P11).

The agent of the CPU 1 which has recognized the END event sends a switching request event to the task A waiting queue of the CPU 2. Until the switching request event is received, the CPU 2 queues the event to the task A in the operation queue but does not process it (FIG. 8B: P12).

After the END event is processed by the CPU1, a switching request event is transmitted to the CPU2 (FIG. 8C: P13).

Next, after processing the switching request event in the CPU1 and CPU2, the events 4 to 5 are executed (FIG. 8).
D). [Recovery in case of CPU failure] Next, a recovery method in case of CPU failure will be described with reference to FIG. When a certain CPU3 fails, a message is sent to the failed CPU3 (see FIG. 1).
0: S20), the agent of the CPU 1 detects the communication failure between the CPUs due to the transmission failure, and determines that the CPU has a failure (FIG. 10: S21).

Upon detecting the CPU failure, the agent of the CPU 1 refers to the task mapping table 3 and requests the CPU having a low load to take over the task information of the failed CPU, and notifies other CPUs of the change of the mapping table. (FIG. 10: S22).

The agent of the CPU requested to take over must take over the local data, but the normal information switching procedure cannot be executed from the faulty CPU.

Therefore, the CPU is bus-connected by the local memory rewriting image shown in FIG. 11 to map the local memory of the faulty CPU to the own CPU.

That is, in FIG. 11, each CPU has a memory access area I for its own CPU and another CP in the memory.
It has a U memory access area II. Normally, nothing is connected to the memory access area II for the other CPU,
In the event of a failure, the memory access area I for the own CPU and the memory access area II for the other CPU are connected to each other by different buses by hardware (FIGS. 10 and 11 :), and the other CPs are connected.
The contents of the memory access area II for U are copied to the memory access area I for its own CPU (see FIGS. 10 and 1).
1 :).

In this way, the necessary information (area II assigned to the mapped task) is expanded from the mapped local memory to the own CPU memory access area I. When the expansion of the memory is completed, the normal operation is performed (FIG. 10: S23).

During this time, the task mapping table update notification is sent to the other CPU (FIG. 10: S22).
Therefore, it is conceivable that the new mapping is already valid and a message notification is sent to the takeover task.

This is dealt with by queuing at the receiving agent until the memory expansion is completed (FIG. 10: S24).

As a result, when a failure occurs in the CPU, it is possible to perform bus switching, inherit local memory information, and perform task switching. [Task takeover sequence at CPU failure] Next, referring to FIG.
2 is a sequence diagram in which a process is handed over to another CPU in the event of a CPU failure without using the N + 1 configuration.

Here, in preparation for the occurrence of a CPU failure, one CPU with a low usage rate is arranged so that the CPU usage rate does not exceed 100% even if the processing of the failed CPU 2 is taken over.

In FIG. 12, the usage rate of each CPU is obtained by the processing up to S7 based on the task rearrangement sequence shown in FIG. Each CPU in the processing step P4
Then, the task relocation is performed based on the mapping table 3.

In this task relocation, the usage rates of the CPU 1 and the CPU 23 are 65 as shown in FIG.
%, 62%, and the usage rate of the CPU 3 arranged as a CPU with a low usage rate is, for example, 8%.

When the CPU 1, which is the host CPU, detects a failure of the CPU 2, it refers to the mapping table 3 to search for a CPU 3 having a low usage rate (processing step P5). Then, a recovery procedure for a CPU failure is executed for the retrieved CPU 3 (processing step P6).

When the agent detects a failure of the CPU 2, the agent searches the CPU 3 having a low operation rate by referring to the task mapping table 3 according to the procedure described above, and as shown in FIG. Inherit all task information that is running within. The usage rate of the CPU 3 at this time is 70%, and the CPU 3 is handed over within a range not exceeding 100%.

Therefore, even if the N + 1 configuration is not adopted, it is possible to secure the recovery destination CPU when a CPU failure occurs and not allow the non-operating CPU to exist by providing the task configuration in which the CPU 3 having a low utilization rate is arranged. It will be possible.

As the recovery destination CPU, the processing can be handed over to the CPU 2 whose operation is guaranteed by handing over the processing to the CPU 3 which is operating even though the operating rate is low.

Further, in the multiprocessor system of the present invention, the tasks can be dynamically arranged and the usage rates of the CPUs can be made substantially uniform. Further, it is possible to dynamically switch the host CPU that instructs the equalization in consideration of the occurrence of a failure or the like.

Here, in the task relocation sequence shown in FIG. 3 described above, C operating as the host
When a failure occurs in PU1, CPU related to CPU2
The usage rate reporting period timer will time out first (FIG. 3: S8), in which case the CPU 2 operates as a host CPU. In this case as well, steps S3 to S7 are similarly repeated. [Message Transmission Restoration Method] Here, in the case of message transmission using inter-CPU communication, it is conceivable that a mismatch occurs between the CPUs in the task mapping table 3 due to a shift in the mapping table update timing during task relocation. . In order to deal with this, a message transmission recovery method when a mismatch occurs in the task mapping table 3 will be described with reference to FIG. 14 and the following table 3 showing the update status of the task mapping table.

[0099]

[Table 3] In FIG. 14, the agent 1 of the CPU 1 is shown in Table 3 above.
By referring to the task mapping table 3 of the agent 1 shown in (1), the task B is recognized as operating in the CPU 2, and a message is transmitted to the CPU 2 (FIG. 14: SS
10).

Upon receiving the message, the agent 2 of the CPU 2 recognizes that the task B is operating in the CPU 1 by referring to Table 3 (2), and sends the message to the CPU 1 (FIG. 14: SS11).

The above steps SS10 and SS11 are repeated until the task mapping table 3 of the CPU 2 is updated.

Then, when the task mapping table 3 of the CPU 2 is normally updated to be as shown in (3) of Table 3 (FIG. 14: SS12), the agent 2 makes the CPU 2
The message is transferred to the task B which operates in.

In the multiprocessor system of the present invention, when the CPUs are individually reset instead of the system reset, there is a possibility that they will time out simultaneously even if the timer values are different.

A time-out occurs simultaneously in CPU1 and CPU2, and CPU1 and CPU2 are the host CPUs.
The recovery operation is shown in FIG. S01: Cycle timer timeout of CPU1 and CPU2
If the individual timer timeouts of
The CPU 1 and the CPU 2 respectively start operating as host CPUs. Since the CPU 2 is activated by default mapping, the task mapping table differs from that of other CPUs. S02: The CPU1 sends a CPU usage rate report request to another CPU. S03, S04: When the CPU2 receives the CPU usage rate report request from the CPU1, the CPU1 recognizes that the cycle timeout has occurred in the CPU1 and stops the operation as the host CPU, but the CPU1 has the individual timer timeout in the CPU2. A CPU usage rate report request is transmitted to notify. S05: CPU2 to CP that received the CPU usage rate report request
Un reports each usage rate to the CPU 1. S06: When the CPU1 receives the CPU usage rate report from another CPU, it updates the task mapping table. C
From PU2, the CPU usage rate is reported as 0%.

S07: The CPU1 sends a task mapping table update message to another CPU. S08: Each CPU updates the task mapping table based on the received task mapping table update message. Then, the period timer is started.

[Calculation method of task running time] A method of calculating each task running time in the own CPU managed by the management table of the "task running time management unit" in the above agent will be described with reference to FIG. FIG. 16A explains the processing at the time of switching for each task, and FIG. 16B is an example of the task running tube table in which the calculated task running time for each task is registered.

As shown in FIG. 16A, the absolute (current) time is read from the reference clock at the task switching timing. The operation time of each task is added to the running time table for each task. The running time of the handler is added as the running time of the operating task before the handler processing, but it is an error.

Each CPU that has received the CPU utilization report request
From the task travel time management table of FIG.
Report the running time of the task running in U to the host CPU. Here, the common function poses a problem when the task task cannot be specified and the task travel time is calculated. In this case, the functional block FB to which the externally provided common function belongs
Is the running time of the task to which

(Supplementary Note 1) In a multiprocessor system for executing a plurality of tasks by a plurality of CPUs, a task mapping table indicating the arrangement state of the plurality of tasks with respect to the plurality of CPUs, which is common to the plurality of CPUs. And a timer having a unique timer value, and the C to which the timer that has timed out previously belongs
Using the PU as a host CPU, the host CPU repeats the relocation of tasks to the plurality of CPUs based on the task allocation state set in the task mapping table and the usage rate of other CPUs. A multiprocessor system characterized by being configured.

(Supplementary Note 2) In Supplementary Note 1, the CP other than the above
The usage rate in U is obtained by an inquiry from the CPU as the host to another CPU.

(Supplementary Note 3) In Supplementary Note 1, further, each of the plurality of CPUs has an externally provided function list in which a task name and a function name are set, and based on the task mapping table and the externally provided function list. , Determining which CPU the object of the externally provided function that accesses the shared memory exists, and when the object exists in another CPU, the other C
A multiprocessor system characterized by sending a function call to a PU.

(Supplementary Note 4) In Supplementary Note 1, further, each of the plurality of CPUs has an operation queue and a standby queue in the switching source task and the switching destination task, and when a task switching event occurs, the switching source task An end (END) event is set after the event to be processed in the operation queue, an event to be continued is set in the operation queue of the switching destination task, and a waiting queue of the switching destination task is set after the end (END) event is processed. A multiprocessor system characterized by performing overtaking control at the time of task switching by sending a switching request message to.

(Supplementary Note 5) In Supplementary Note 1, the plurality of C
Each of the PUs has a memory access area for its own CPU and a memory access area for another CPU in the local memory, and when one CPU fails, the one CPU
The multiprocessor system is configured so that the memory access area for its own CPU and the memory access area for other CPUs of the switching destination CPU are connected by bus switching to take over the information of the local memory.

(Supplementary Note 6) In Supplementary Note 1, the plurality of C
The PU is set to have a low usage rate of at least one CPU with respect to other CPUs, and when one of the other CPUs fails, the one CPU is set as a recovery destination CPU. Processor system.

(Supplementary Note 7) In Supplementary Note 1, the other CP
The usage rate in U is obtained by an inquiry from the CPU as the host to another CPU.

[0116]

As described above with reference to the drawings, according to the present invention, the software configuration is easy and the processing overhead can be reduced as compared with the conventional multiprocessor system. In addition, multiprocessor communication with excellent function distribution, load distribution, and failure recovery can be realized, which shortens the development period and makes it easy to add functions.
It greatly contributes to the reduction of bugs.

[Brief description of drawings]

FIG. 1 is a diagram showing a configuration example of a multiprocessor system to which the present invention is applied.

FIG. 2 is a diagram showing a configuration example of one CPU of the multiprocessor system shown in FIG.

FIG. 3 is a diagram showing an example of task relocation according to the present invention.

FIG. 4 is a diagram showing an image of equalizing CPU usage rates.

FIG. 5 is a diagram showing an outline of message transmission scheduling.

FIG. 6 is a diagram showing an example of an embodiment in which an externally provided function call is made between processors.

FIG. 7 is a diagram showing details of a method of scheduling an externally provided function for accessing a shared memory.

FIG. 8 is a diagram showing an overtaking control image.

9 is a diagram showing a procedure of overtaking control when task switching occurs between CPUs in association with FIG. 8. FIG.

FIG. 10 is a diagram illustrating a recovery method when a CPU failure occurs.

FIG. 11 is a diagram showing a local memory rewriting image.

FIG. 12 is a diagram showing a sequence in which processing is handed over to another CPU when a CPU fails without using the N + 1 configuration.

FIG. 13 shows CPU1 and CPU in task relocation.
It is a figure in which the usage rate of 23 is shown in FIG.

FIG. 14 is a diagram illustrating a message transmission restoration method.

FIG. 15 is a diagram showing a recovery operation in the case where a timeout occurs at the same time in the CPU1 and the CPU2, and each of them operates as a host CPU.

FIG. 16 is a diagram illustrating a method of calculating task travel time.

[Explanation of symbols]

1 agent 2 Function list table 3 task mapping table 4 multiple tasks

   ─────────────────────────────────────────────────── ─── Continued front page    (72) Inventor Koji Higuchi             2-2-1 Hyakudohama, Sawara-ku, Fukuoka, Fukuoka               Fujitsu West Japan Communication System             Thames Co., Ltd. (72) Inventor Hiroshi Wakameda             2-2-1 Hyakudohama, Sawara-ku, Fukuoka, Fukuoka               Fujitsu West Japan Communication System             Thames Co., Ltd. (72) Inventor, Joji Furuya             2-2-1 Hyakudohama, Sawara-ku, Fukuoka, Fukuoka               Fujitsu West Japan Communication System             Thames Co., Ltd. F-term (reference) 5B045 BB28 BB32 DD05 EE25 EE29                       GG04 JJ13 JJ26 JJ44                 5B098 AA10 GA04 GB14 GC08 GD02                       GD14

Claims (5)

[Claims] 1. In a multiprocessor system for executing a plurality of tasks by a plurality of CPUs, a task mapping table indicating the arrangement state of the plurality of tasks with respect to the plurality of CPUs, which is common to the plurality of CPUs. A multiprocessor system comprising means for switching between the plurality of CPUs a host CPU that performs task rearrangement for the plurality of CPUs based on the arrangement state of the tasks set in the task mapping table. 2. In a multiprocessor system for executing a plurality of tasks by a plurality of CPUs, a table showing a task allocation state of each of the plurality of CPUs, a task allocation state set in the table, and each CP.
A multiprocessor system having means for rearranging tasks to the plurality of CPUs based on a usage rate in U. 3. The CPU according to claim 1, further comprising: an externally provided function list in which a task name and a function name are set, and based on the task mapping table and the externally provided function list, It is determined which CPU has an object of an externally provided function that accesses the shared memory, and when the object exists in another CPU, a function call is sent to the other CPU by inter-CPU communication. Multiprocessor system to do. 4. The switching CPU according to claim 1, wherein each of the plurality of CPUs has an operation queue and a standby queue in a switching source task and a switching destination task, and when a task switching event occurs, the switching source task An end (END) event is set after the event to be processed in the operation queue, an event to be continued is set in the operation queue of the switching destination task, and a waiting queue of the switching destination task is set after the end (END) event is processed. By sending a switch request message,
A multiprocessor system characterized by performing overtaking control when switching tasks. 5. The CPU according to claim 1, wherein each of the plurality of CPUs has a local memory,
A memory access area for its own CPU and a memory access area for another CPU are provided. When a failure occurs in one CPU, its own C
PU memory access area and other CP of the switching destination CPU
A multiprocessor system characterized in that the memory access areas for U are connected by bus switching and the information in the local memory is taken over.