JPH0546417A - Multiprocessor system control method - Google Patents

Abstract

PURPOSE:To efficiently use a system by reporting the request of a task of in arbitrary processor to the other processors through a shared memory to execute tasks of processors even at the time of trouble of the shared memory. CONSTITUTION:In an event driven multiprocessor system control method where plural processors 10, 20, and 30 having private memories 12, 22, and 32 and a shared memory 41 are connected by a common bus 40 and the task execution order of the other processors can be changed by the request of the task of one processor, tasks to be executed by processors and task management data 13, 23, and 33 which control the execution order of tasks are recorded in private memories 12, 22, and 32 of processors 10, 20, and 30. The request of one processor is reported to the other processors through the shared memory 41. Consequently, tasks are executed in each processor even if the shared memory 41 is faulty, and the increase of unused memory blocks in the shared memory 41 is prevented to efficiently use the system.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a multiprocessor system control system, and more particularly to a multiprocessor system control system for controlling the execution order of tasks executed in a multiprocessor system.

In a recent communication processing apparatus, the number of lines accommodated in one apparatus is increasing, and it is required that various communication protocols are supported, and high reliability must be guaranteed. As a solution to meet these demands, a communication processing device composed of multiprocessors has appeared. Real-time processing is important in communication processing, and it is desirable that the conventional kernel for real-time processing can be used in a multiprocessor system. Here, the kernel is the operating system (O
Part of S) controls the task execution order.

[0003]

2. Description of the Related Art Conventional multiprocessor systems are roughly classified into a loosely coupled multiprocessor system in which processors are connected by a LAN or the like and a tightly coupled multiprocessor system using a common memory. In the loosely coupled multiprocessor system, since synchronous communication between processes arranged in each processor cannot be directly managed, a process that performs interprocessor communication processing with other processors intervenes to manage the execution order of each process. In this method, the independence of each processor is high, and there is an advantage that the failure of a specific processor does not affect the execution of other processors, but the response of the processing performed in cooperation between the processes of different processors is slow, The performance required for the communication processing device may not be satisfied in some cases.

On the other hand, in the tightly coupled multiprocessor system, by arranging management information for controlling the execution order of processes in a common memory, it is possible to execute processes arranged in a plurality of processors in parallel. The passing of data between processes has the advantage that it can be processed at high speed by the common memory. In addition, it is necessary to effectively use the common memory when performing data communication between processors in a multiprocessor system. In one processor, a method of dynamically acquiring / returning a memory block is generally performed by memory management by a memory pool as an area for communication between tasks.

[0005]

In the conventional tightly coupled multiprocessor system, the management information for controlling the execution order of processes is arranged in the common memory. Therefore, if a failure occurs in the common memory, all the processors cannot operate and are fatal. There was a problem of being a target.

Further, when a system is adopted in which the entire system operates even if a specific processor of the multiprocessor system fails, the memory block in the shared memory acquired by the specific processor remains unreturned in the system. Since the operation continues, there is a problem that each time the processor fails, the number of memory blocks that are not returned to the common memory and are not returned is increased and the efficiency is poor.

The present invention has been made in view of the above points,
It is an object of the present invention to provide a multiprocessor system control method in which each processor can execute a task even when a failure occurs in the common memory, prevent an unused memory block from increasing in the common memory, and efficiently use the memory block.

[0008]

A multiprocessor control system according to the present invention comprises a plurality of processors each having a dedicated memory,
In the event-driven multiprocessor system control method, in which a common memory is connected by a common bus, and the task execution order of other processors can be changed according to the task request of any processor, each dedicated memory of multiple processors The task management data that controls the tasks executed by the processor and the execution order of the tasks is stored, and the request of the task of any processor is notified to another processor via the common memory.

Further, each of the plurality of memory blocks acquired by each processor from the memory pool provided in the common memory sets ownership in each processor, and communication between the processors is performed. Returns the memory block for which the ownership of its own processor is set among the memory blocks of.

[0010]

In the present invention, since each kernel controls the task execution order by the task management information stored in the dedicated memory of its own processor, the tasks can be executed by each processor even when the common memory fails, and the influence of the failure is small. Complete.

Further, since the processor recovered from the failure returns the memory block owned by its own processor in the memory pool, the unused memory block is prevented from increasing in the memory pool.

[0012]

2 is a block diagram of an embodiment of a multiprocessor system of the present invention.

In the figure, reference numerals 10, 20, 30 denote processors, which have synchronization / communication control processing units 11, 21, 31 and storage devices 12, 22, 32 as dedicated memories.

The storage devices 12, 22, 32 are synchronized with each other.
A plurality of processing programs 1 to n used by each of the communication control processing units 11, 21 and 31 are stored, a kernel for controlling the task execution order of the processing programs 1 to n, and a ready storing the executable tasks. Task management information such as an event waiting queue that stores queues and tasks waiting for events, and synchronization / communication management information 13, 23, 33
Is stored.

The synchronization / communication control processing units 11, 21, 31 of each processor 10, 20, 30 are connected to a common bus 41, and a common memory is connected to the common bus 40. The synchronization / communication control processing units 11, 21, 31 are connected by a control line 42.

FIG. 1 shows the principle of the first embodiment of the method of the present invention. Here, processor 10 to processor 20
The case of controlling will be described.

In the figure, a common memory 41 is set with a data transfer area for transferring data between the kernel of each processor and the kernel of another processor, and the data transfer area 45 is the kernel 15 of the processor 10. It is a dedicated area between the processor 20 and the kernel 25.

When the kernel 15 of the processor 10 receives the parameter of the system call requested by the task 16 being executed, it checks the processor identification number on the parameter 17 and if it is a system call to the processor 20, this parameter 17 is shared. After writing in the data transfer area 45 of the memory 41, the bit corresponding to the own processor of the NMI (non-maskable interrupt) register 26 of the processor 20 is turned on. The NMI register 26 has a bit set for each of the other processors and is for recognizing the highest priority interrupt from the other processors.

The NMI interrupt processing unit 27 of the processor 20
Reads the contents of the NMI register 26, recognizes the interrupt request from the processor 10, reads the parameter 17 from the data transfer area 45 of the common memory 41, and issues the system call of the parameter 17 to the kernel 25 of the own processor. That is, the system call by the task 16 of the processor 10 is substituted.

The kernel 25 performs the service instructed by the parameter 17 with respect to the task management information / synchronous communication management information 23 in its own processor, for example, the processor 10
The execution of the task 29 of the event wait request which has been waiting for the system call is started. After that, the kernel 25 notifies the NMI interrupt processing unit 27 of the end information 24 as a result of performing the above service. The NMI interrupt processing unit 27 writes this end information 24 in the data delivery area 45.

After writing the parameter 17 in the common memory 41, the kernel 15 of the processor 10 reads the end information 24 from the data transfer area 45 a predetermined number of times every predetermined period, and the end information 24 is stored by the processor 20. If so, the end information is notified to the task 16. If the end information is not stored during this time, the kernel 15 notifies the task 16 as a communication error.

As described above, the kernels 15 and 25 only execute the synchronous control and the task scheduling for the tasks in the self-processors 10 and 20, and the kernels 15 and 25 respectively store the storage devices (local memory) of the self-processors 10 and 20. ) Task 1 using task management information / synchronous communication management information 13 and 23 arranged in 12 and 22
In order to control the execution order of 6, 29, etc., the common memory 41
It is possible to configure an event driven system that does not affect the task execution control in each processor 10 or 20 even if a failure occurs. This event-driven system is a system that changes the task execution order of other processors in response to a task request of an arbitrary processor. Further, the synchronous control between the tasks 16 and 29 is performed by the common memory 4
Since the processing is performed via 1, it is possible to perform high-speed real-time processing.

FIG. 3 is a block diagram of the second embodiment of the method of the present invention. In the figure, those parts which are the same as those corresponding parts in FIG. 1 are designated by the same reference numerals, and a description thereof will be omitted.

In FIG. 3, each of the processors 10 and 20 uses the memory block acquisition / return functions 50 and 60 in the kernels 15 and 25 to cause the memory pool 7 of the common memory 41 to operate.
Use memory blocks in 0 dynamically. Each memory block 71, 72, ... Of the memory pool 70 is provided with ownership setting areas 71a, 72a for storing ownership, and stores the identification number of the processor that returns this memory block.

When there is a request from the processor 10 to send a message to the processor 20, the memory block acquisition / return function 50 in the kernel 15 of the processor 10 has the ownership not determined, for example, the area 72a of the memory block 72.
The identification number of its own processor is written in, and the message transmission function 51 writes the transmission message to the processor 20 in the memory block 72. Also, the kernel 15 notifies the parameter 25 of this message transmission to the kernel 25 of its own processor. As a result, the memory block acquisition / return function 60 in the kernel 25 writes the identification number of its own processor in the ownership setting area 72a of the memory block 72, and then the kernel 25 reads the contents of the memory block 72. After that, the kernel 25 notifies the NMI interrupt processing unit 27 of the end information 53 as a result of reading the message.
The NMI interrupt processing unit 27 writes this end information 53 in the data delivery area 45.

After writing the parameter 17 in the common memory 41, the kernel 15 of the processor 10 reads the end information 53 from the data transfer area 45 a predetermined number of times at a predetermined period.

The responsibility for returning the memory block 72 is from the processor 10 to the processor 2 when the ownership is acquired.
When the message reception by the processor 20 ends normally, the memory block acquisition / return function 60 in the kernel 25 erases the identification number of the own processor in the ownership setting area 72a of the memory block 72, thereby causing the memory block 72 Is returned as an unused state.

Further, if the processor 20 fails for some reason while the ownership of the memory block 72 is in the processor 20, the memory block 72 is not returned, and its contents are also saved. When the processor 20 removes the cause of the failure and starts processing, the initialization function 61 in the kernel 25 is activated, and among the memory blocks managed by the memory pool 70, such as the memory block 72 owned by the processor 20. The identification number of its own processor such as the ownership setting area 72a is erased and returned.

As a result, the unnecessary memory block 72 is returned to the memory pool 70, and the task 2 of the processor 20 is returned.
9 and the like can start the processing from a state where there is no memory block having the ownership of the own processor in the memory pool 70, and can prevent the unused memory block from increasing in the memory pool 70 of the common memory 41. Can be used efficiently.

[0030]

As described above, according to the multiprocessor system control method of the present invention, each processor can execute a task even when a failure occurs in the common memory, and it is possible to prevent an unused memory block from increasing in the common memory. It can be used efficiently and is extremely useful in practice.

[Brief description of drawings]

FIG. 1 is a diagram illustrating the principle of a first embodiment of the system of the present invention.

FIG. 2 is a configuration diagram of an embodiment of a multiprocessor system according to the present invention.

FIG. 3 is an explanatory view of the principle of the second embodiment of the system of the present invention.

[Explanation of symbols]

 10, 20, 30 Processor 13, 23, 33 Task management information / synchronous communication management information 15, 25 Kernel 16, 29 task 27 NMI interrupt processing unit 40 Common bus 41 Common memory 50, 60 Memory block acquisition / return function 51 Message transmission function 61 initialization function 70 memory pool 71, 72 memory block 71a, 72a ownership setting area

Claims (2)

[Claims] 1. A plurality of processors (10, 20, 30) each having a dedicated memory (12, 22, 32) and a common memory (41) are connected by a common bus (40) so that a task of an arbitrary processor can be processed. In an event-driven multiprocessor system control method in which the task execution order of other processors can be changed according to a request, dedicated memories (12, 22, 32) of the plurality of processors
Task management data (13, 23, 33) that controls the tasks executed by each processor and the task execution order
And stores the request of the task of any processor in the common memory (4
A multiprocessor system control method characterized by notifying other processors via 1). 2. The multiprocessor system control method according to claim 1, wherein a plurality of memory blocks (71, 71) acquired by each processor from a memory pool (70) provided in a common memory (41).
72) Ownership is set in each processor and communication between processors is performed, and the processor recovered from the failure is in the memory pool (70).
Of the plurality of memory blocks (71, 72) in which the ownership of the own processor is set is returned.