JP3841229B2 - Message synchronous data processing system - Google Patents

Description

[0001]
[Industrial application fields]
The present invention is made up of a plurality of processor modules, the arrangement to continue to perform data processing while synchronizing while accessing the other spatial relates Message synchronous data processing system take according to the message, in particular, profile processor module crashes The present invention relates to a message synchronous data processing system capable of promptly notifying the occurrence of a crash to the space of a message transmission source that is in a waiting state.
[0002]
[Prior art]
FIG. 10 illustrates a system configuration of a message synchronous data processing system to which the present invention is applied.
[0003]
As shown in the figure, in the message synchronous data processing system to which the present invention is applied, in terms of hardware, a plurality of processor modules (PM in the figure) composed of a CPU, a memory and the like are coupled by a bus or a line. On the other hand, in terms of software, each processor module develops a kernel (core) and develops a plurality of spaces depending on functional units, resource types, and the like.
[0004]
Each space is independent from each other and protected from mutual interference by the walls of the space. When accessing another space, a destination CAP (Capability) as a transmission destination is designated to communicate a message. To do. Here, this CAP is managed in association with a space, and a server having the authority to issue a CAP issues it in response to a space issuance request.
[0005]
In a message synchronous data processing system employing such a system configuration, as shown in FIG. 11, the space on the transmission side enters a waiting state when a request message for a processing request is transmitted. On the other hand, when receiving the request message, the receiving space enters the execution of the request process, and when the process ends, specifies the reply CAP (displays the reply destination) that is notified when the request message is received. Then, a reply message is transmitted to the transmission side space. Upon receiving this reply message, the transmitting side space releases the waiting state and resumes execution of its own processing. Note that the reply CAP in the receiving side space is deleted when the reply message is transmitted.
[0006]
In this way, the message synchronous data processing system adopts a configuration in which data processing is executed according to message passing.
In this message synchronous data processing system, when a crash occurs in the reception side space as shown in FIG. 12 or when a crash occurs in the processor module that expands the reception side space as shown in FIG. Will remain waiting.
[0007]
In order to solve such an inconvenience, conventionally, the transmission side space operates a timer after transmitting a request message, and when a reply message is not returned even after a specified time has elapsed, a space crash or processor As the module crash occurred, the wait state was released.
[0008]
[Problems to be solved by the invention]
However, according to such a conventional technique, even if a space crash or a processor module crash occurs at the destination of the request message, the sending side space cannot detect it until it times out. there were. As a result, there is a problem that the waiting state after sending the request message cannot be quickly released when a crash occurs.
[0009]
The present invention was made in view of such circumstances, profile processor when the module crash, against message source space, a new message synchronization to allow fast notification of this crash The purpose is to provide a type data processing system.
[0010]
[Means for Solving the Problems]
FIG. 1 illustrates the principle configuration of the present invention.
In the figure, 1 is a plurality of processor modules, 2 is a communication path for connecting the processor modules 1, 3 is a kernel developed in each processor module 1, 4 is deployed in the processor modules 1, The transmission side space 5 is expanded in association with the transmission side space 4, the transmission destination information management unit for managing the transmission destination information for displaying the transmission destination of the request message, and 6 is expanded in the processor module 1. A receiving space for executing a process on the message and returning a reply message, and 7 is expanded in association with the receiving space 6 and reply destination information management for managing reply destination information for displaying a reply destination of the reply message. Part.
[0012]
In Fig. 1, 10 is provided in the request message destination of the processor module 1 correspondence, the management table for managing the return destination information, 11 are expanded to the kernel 3, executes the management process of the management table 10 table The management unit 12 is expanded in the kernel 3 and the PM crash detection unit 13 detects the crash of the other processor module 1. The proxy 13 is expanded in the kernel 3 and displays the processor module crash for the transmission side space 4. It is a proxy message transmission unit that transmits a message.
[0016]
[Action]
In the present invention configured as described above, the table management unit 11 of the kernel 3 in which the transmission side space 4 is expanded sends a request message to the reception side space 6 in which the transmission side space 4 is expanded in the other processor module 1. When transmission is performed, the reply destination information to be included in the reply message to be returned is registered in the management table 10 associated with the processor module 1, and the reception side space 6 of the other processor module 1 is the transmission side space of its own module. When the reply message is sent back to 4, the reply destination information of the reply message is deleted from the management table 10 associated with the processor module 1. In accordance with this processing, the management table 10 performs processing so as to manage unreplied ones in reply destination information included in reply messages transmitted from other modules.
[0017]
In this way, when the management table 10 manages the reply destination information that has not been replied, the PM crash detection unit 12 of the kernel 3 deployed in the transmission side space 4 detects a crash of the other processor module 1. The proxy message transmission unit 13 of the kernel 3 transmits the proxy reply message that displays the processor module crash by designating the reply destination information of the management table 10 associated with the crash module, instead of the receiving side space 6. Transmit to side space 4. Then, upon receiving the transmission of the proxy reply message, the transmission side space 4 detects a crash of the processor module 1 in which the reception side space 6 is expanded, and cancels the waiting state that is entered after the transmission of the request message.
[0018]
As described above , in the present invention, when a crash occurs in the processor module 1 in which the reception side space 6 is expanded, the kernel 3 transmits a proxy reply message to the transmission side space 4, thereby allowing Since the configuration in which the crash of the module 1 is notified is adopted, the transmission side space 4 can quickly recognize the crash of the processor module 1 deployed in the reception side space 6 and waits after the request message is transmitted. The state can be released quickly.
[0019]
【Example】
Hereinafter, the present invention will be described in detail according to examples.
FIG. 2 shows an example of a detailed table configuration of the management table 10 described in FIG. In the figure, reference numeral 100 is provided for the destination processor module 1 ( provided for each destination processor module 1) , and manages a reply CAP serving as reply destination information, a version code for displaying the IPL count, and the like. A transmission destination PM management table (hereinafter abbreviated as IPCL in the figure) 101 is a hash table for hash management of the transmission destination PM management table 100.
[0020]
The kernel 3 of the processor module 1 executes the management process of the reply CAP in the transmission destination PM management table 100. FIG. 3 shows a processing flow of this management processing executed by the kernel 3.
[0021]
When the transmission side space 4 of each processor module 1 transmits a request message to the reception side space 6 of another module, as shown in the processing flow of FIG. In step 1, a reply CAP to be designated by a reply message that is a response to the request message is registered in the corresponding destination PM management table 100. Next, in step 2, the kernel identifier 3 of the transmission destination processor module 1 is notified of an entry identifier indicating which entry in the transmission destination PM management table 100 has registered the reply CAP, and the processing is terminated.
[0022]
In this way, when receiving the entry identifier of the destination PM management table 100 from the kernel 3 of the transmission source processor module 1, kernel 3 on the receiving side, the entry identifier to reply destination information management unit 7 of the module itself You will register. The receiving side space 6 uses the reply CAP to which this entry identifier is added when sending a reply message.
[0023]
FIG. 4 illustrates a process for registering a reply CAP to the transmission destination PM management table 100 executed according to the processing flow of FIG.
On the other hand, when a reply message is transmitted to the transmission side space 4 of its own module, the kernel 3 of each processor module 1 starts with step 1 as shown in the processing flow of FIG. Then, it is determined whether or not the reply message is a reply message between the program modules 1. If it is determined that this is a reply message transmitted from another module, the process proceeds to step 2 and the entry identifier in the destination PM management table 100 is extracted from the reply CAP of the transmitted reply message.
[0024]
Subsequently, in step 3, the transmission destination PM management table 100 associated with the processor module 1 that is the transmission source of the reply message is searched, and the reply CAP indicated by the entry identifier extracted in step 2 is searched. Subsequently, in step 4, it is determined whether or not the reply CAP included in the reply message transmitted matches the reply CAP searched in step 3. The reply CAP is deleted from the destination PM management table 100. At this time, the reply message is distributed to the mailbox pointed to by the reply CAP, so that the transmission side space 4 is notified.
[0025]
On the other hand, if it is determined in step 4 that they do not match, it indicates that the reply message has already been received, so the processing is terminated without executing the deletion processing in step 5. At this time, the reply message is discarded. When it is determined in step 1 that the reply message is in the same module, it is out of the management target of the transmission destination PM management table 100, so that the processing in steps 2 to 5 is not executed. The process is terminated as it is.
[0026]
FIG. 5 illustrates a process for deleting a reply CAP from the transmission destination PM management table 100, which is executed according to the processing flow of FIG.
In this way, the kernel 3 of each processor module 1 executes the processing flow of FIG. 3, so that the transmission destination PM management table 100 developed in its own module receives the reply message transmitted from another module. The processing is performed so as to manage the non-reply replies within the reply CAP.
[0027]
Next, a recovery process of the kernel 3 executed when a space crash occurs in the receiving side space 6 and when a crash occurs in the processor module 1 will be described. FIG. 6 shows a processing flow of this recovery processing executed by the kernel 3.
[0028]
Kernel 3 of each processor module 1 to expand the receiving side space 6 detects space crash receiving side space 6 which is open exhibition to the own module, as shown in the process flow of FIG. 6 (a), the first of In step 1, a reply CAP managed by the reply destination information management unit 7 associated with the crashed receiving space 6 is searched. Next, in step 2, the retrieved reply CAP is designated as a destination, a proxy reply message indicating a space crash is transmitted to the transmission side space 4, and the process is terminated.
[0029]
When this proxy reply message is received, the transmitting side space 4 in the waiting state recognizes a space crash in the receiving side space 6 and releases the waiting state.
FIG. 7 illustrates an explanatory diagram of the proxy reply message transmission process when the space crash receiving side space 6 is expanded to its own module, and FIG. 8 illustrates the space crash receiving side space 6 expanded to other modules. FIG. 6 illustrates an explanatory diagram of a proxy reply message transmission process at a time.
[0030]
In this way, when a space crash occurs in the reception side space 6, the kernel 3 notifies the transmission side space 4 of the occurrence of the space crash by transmitting a proxy reply message to the transmission side space 4. It is processed as follows.
[0031]
The kernel 3 of the processor module 1 that expands the transmission side space 4 receives the proxy reply message transmitted from the processor module 1 when the reception side space 6 in which the space crash has occurred is expanded to another module. Similarly to the case of receiving a normal reply message, the process of deleting the corresponding reply CAP from the transmission destination PM management table 100 is executed according to the processing flow of FIG.
[0032]
On the other hand, when the kernel 3 of each processor module 1 that expands the transmission side space 4 detects a crash of the other processor module 1, first, as shown in the processing flow of FIG. The transmission destination PM management table 100 associated with the processor module 1 in which the error occurred is searched to obtain a reply CAP. Next, in step 2, the acquired reply CAP is designated as a destination, a proxy reply message for displaying a processor module crash is transmitted to the transmission side space 4, and the process is terminated.
[0033]
When this proxy reply message is received, the transmitting side space 4 in the waiting state recognizes the crash of the processor module 1 that expands the receiving side space 6 and releases the waiting state.
[0034]
FIG. 9 illustrates an explanatory diagram of the proxy reply message transmission process when the processor module crashes.
As described above, when a crash occurs in the processor module 1 that expands the reception side space 6, the kernel 3 transmits the proxy reply message to the transmission side space 4, thereby notifying the transmission side space 4 of the occurrence of the crash. It is processed to notify.
[0035]
The kernel 3 of the processor module 1 that expands the transmission side space 4 deletes the corresponding reply CAP from the destination PM management table 100 when transmitting the proxy reply message in accordance with the crash of the other processor module 1. Will be executed.
[0036]
【The invention's effect】
As described above, according to the present invention, in the message-synchronous data processing system employing a configuration that continue to perform data processing while synchronizing while accessing the other space in accordance with the message, the processor of the receiving-side space When the module crashes, the kernel sends the proxy reply message that indicates the crash to the sender space, so that the sender space is notified of the crash. This crash can be recognized quickly, and the waiting state after sending the request message can be released quickly.
[Brief description of the drawings]
FIG. 1 is a principle configuration diagram of the present invention.
FIG. 2 is an example of a table configuration of a management table.
Figure 3 is an example of a processing flow executed by the car, channel.
FIG. 4 is an explanatory diagram of registration processing of a reply CAP to a transmission destination PM management table.
FIG. 5 is an explanatory diagram of processing for deleting a reply CAP from a destination PM management table.
6 is an example of a processing flow executed by the car, channel.
FIG. 7 is an explanatory diagram of processing at the time of a space crash.
FIG. 8 is an explanatory diagram of processing at the time of a space crash.
FIG. 9 is an explanatory diagram of processing when a processor module crashes;
FIG. 10 is an explanatory diagram of a message synchronous data processing system.
FIG. 11 is an explanatory diagram of a message synchronous data processing system.
FIG. 12 is an explanatory diagram when a crash occurs.
FIG. 13 is an explanatory diagram when a crash occurs.
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 1 Processor module 2 Communication path 3 Kernel 4 Transmission side space 5 Transmission destination information management part 6 Reception side space 7 Reply destination information management part
1 0 Management table 11 Table management unit 12 PM crash detection unit 13 Proxy message transmission unit

Claims (1)

The transmission side space is composed of a plurality of processor modules, specifies the transmission destination information, transmits a request message, and enters a waiting state, while the reception side space indicated by the transmission destination information is the transmission side space. In the message synchronous data processing system adopting a configuration in which the reply destination information indicating the address is designated and the reply message that triggers the release of the waiting state is transmitted.
The kernel of the processor module that expands the sender space
When a request message is transmitted to the receiving side space developed in the other processor module, the reply destination information specified by the receiving side space developed in the processor module in units of the destination processor module the management means for managing registers the reply destination information of the corresponding, when the response message over the processor module is transmitted to the transmission side space of its own module, the reply destination information held by the reply message Deleting from the management means ;
A crash occurrence of another processor module or by looking up shall correspond to the crash module from the reply destination information managed by the managing means, specifying the receiving side space that is extracted to the crash module Locate and a composed reply destination information, in place of the receiving-side space, by specifying the retrieved reply destination information, in that it comprises means for transmitting a proxy reply message indicating a processor module crash,
Characteristic message synchronous data processing system.

Images