JPH09146903A - Data transfer control method for parallel computer - Google Patents

Abstract

PROBLEM TO BE SOLVED: To transmit and receive messages safely on a parallel computer by using remote memory transfer. SOLUTION: When messages are transmitted to and received from the parallel computer by remote memory transfer, the respective element computers are provided with an arbitrary number of memory areas 122 and 123 that can be accessed remotely and their management areas 124 and 125, and flags for remote access inhibition are provided in the management areas for the respective memory areas, thereby optionally allowing the areas to be accessed remotely or inhibiting them from being accessed remotely. Consequently, data are prevented from being overwritten to the same memory area owing to multiple writing and illegal data are prevented from being read out owing to the repetition of writing to and reading from the same memory area.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to data communication between PUs in a parallel computer in which a plurality of elemental computers (processing units, hereinafter referred to as PUs) are connected by a communication network, and particularly data communication is performed without intervention of a partner PU. Relating to ensuring data safety when transferring data to remote memory.

[0002]

2. Description of the Related Art A parallel computer improves processing speed by connecting a plurality of PUs via a communication network and operating them simultaneously. The present invention is particularly directed to a distributed memory type parallel computer in which each PU can access only the memory space associated with it. The distributed memory parallel computer cannot directly access the data in the memory of another PU. Every time data is needed, it is necessary to perform transmission / reception to move the data to its own PU.

In a distributed memory type parallel computer, it is necessary to describe all data exchange between PUs in a program. Here, the data passed between PUs is called a message. In a parallel computer program, if the data required by another PU is in the memory of its own PU, it is sent in advance, and if the data in the memory of another PU is needed by its own PU, It is necessary to explicitly describe the instruction to be received in advance in the program of each PU. In many parallel computer systems, in order to support the sending and receiving of messages between such PUs,
A group of functions (or subroutines) called a message passing library is prepared in advance, and communication can be described as a function call from a program such as "C" or "FORTRAN". Some message passing libraries have been implemented on different parallel computer hardware to provide a de facto standard communication environment. US Oa
k Ridge National Laborato
PVM developed by ry and MPI (Message Passing Inte), which has been standardized in recent years.
rface) is an example. A parallel program written by calling these communication libraries has a high possibility (portability) to be operated only by recompiling on a different parallel computer.

Two types of methods are known for passing messages between PUs in a communication library. First, the sending PU calls the send function of the message,
This is a method in which a PU on the receiving side calls a corresponding message receiving function and a message is transmitted and received between them. If the receiving function is called before the sending function, the receiving function blocks (stops) until the arrival of data, and if the sending function is called first, blocks until the receiving function is issued, or the message is set by the system. It is generally buffered in. This is send / receive
It is called the ive method. Secondly, the sending PU writes the message to the other PU just by calling the message sending function (without issuing the corresponding receiving function), or by calling the receiving function (without issuing the corresponding sending function). This is a method of reading data from the partner PU. This is called the put / get method or the remote memory copy method. The send function is the put function and the receive function is the ge function.
It is called the t function.

Of the standard message passing libraries listed above, PVM only supports communication by the send / receive system. MPI is also sen
Only the d / receive system is supported, but MPI-which is currently under consideration as a time version
In 2 there is a plan to incorporate communication by the put / get method in addition to this.

In the send / receive system, since the PUs on the transmitting side and the receiving side each issue a sending function and a receiving function to explicitly deliver the message, the user is at which timing the message is sent to which memory area of its own PU. Can be sent and received. However, since the user must always associate transmission and reception in the program, the work of the program is great. On the other hand, in the put / get method, the transmitting side and the receiving side unilaterally read / write data on the partner PU. Since it is sufficient to issue either put or get when the data is needed, the labor of the program is reduced.
However, if the message sending / receiving memory area is wrong, or if two or more PUs read / write to the same memory area almost simultaneously, the data will be destroyed, the data will be overwritten, or the wrong data will be written. Might read out.

In MPI-2, in order to prevent the user program from being destroyed due to an error in the transmission / reception destination memory area, each PU is provided with a function for ensuring a memory area dedicated to put / get. Put / get operation is performed for each P
Since the message can be sent and received only to the area secured in advance by U, there is no possibility of accidentally writing and reading to other memory areas.

Hereinafter, the message passing library MP
An outline of a message communication method using the put / get function proposed in I-2 will be described. However, in order to simplify the explanation, the function specifications are partially simplified.

When using MPI, the following MPI initialization function is called on all programs participating in communication. Normally, this process is performed at the beginning of the parallel program.

Init () In this function, the message passing library performs necessary initialization operations. The functions listed below can only be used after calling the initialization function.

When using put / get at the initial stage or after the end, the following function for securing a dedicated memory area for put / get on all PUs is called.

Rmc_malloc (base, si
ze, id) where base is the start address of the memory area (window) to be secured, and size is the length of the memory area. i
d is a window identifier and is an output argument of this function. By calling this function multiple times, it is possible to provide an arbitrary number of windows on one PU. A counter that can be set from the get / put function is automatically attached to the window created by this function. Although this counter cannot be directly accessed by the user, the completion of the put / get operation for the window can be detected by monitoring the value of the counter using a handler described later.

Put operations for windows of other PUs are executed by the following function call. Put (origin_addr, origin_s
size, target_rank, id, inc
r) where origin_addr, origin_si
ze is the start address and length of the memory of the own PU in which the message to be sent is stored. target_rank
Is the PU number of the destination. id indicates a window on the partner PU to be put. incr represents the increment value of the counter attached to the window, and at the same time as writing the message, the counter of the put-destination window is incremented by the value specified here.

On the other hand, the get operation is performed by the following function call.

Get (origin_addr, or
igin_size, target_rank, i
d, incr) The meaning of each argument is the same as in the case of get. However, in this function, the message is read from the window of the partner PU and is received by the memory after the origin_addr of the own PU.

Completion of the put / get operation is judged by whether or not the counter exceeds the upper limit value designated by the user in advance. Here, the upper limit value of the counter can be set by the user by calling the following function for each window.

Set_counter_thresh
ld (id, count) id is a window identifier, and count is an upper limit value to be set. When the counter exceeds the upper limit value, the handling function registered in advance by the user is called back by MPI. The handling function is set by the following function call.

Post_handler (id, handler) id is the identifier of the window that is the call target of the handling function, and handler is a pointer to the handling function. The handling function itself can be freely described by the user. If the upper limit value of the counter is designated as 1 and the argument incr of put / get is also designated as 1, the handling function can be called at the end of each put / get. In addition, the upper limit value of the counter and i
By changing the value specified by ncr as appropriate, p
It is also possible to call the handling function when ut / get ends.

The above is a description of the put / get operation method from the user program when MPI is used.

[0020]

As described above, put /
Although the get method is a dangerous communication method that may potentially destroy data, two or more PUs read from and write to the same memory area in the conventional message passing library including MPI. No consideration was given to the case. Further, when the data is unexpectedly destroyed by the put / get operation, the user has no means for detecting it.

An object of the present invention is to provide a message passing library for a distributed memory parallel computer in which
It is possible to prevent duplicate writing of messages to the same memory area by ut / get operation, and to detect when there is duplicate writing to the same memory area. It is to improve safety.

[0022]

The present invention is a put / ge
In transmission and reception by the t method, p is set on each PU in order to prevent data overwriting and erroneous data reading by issuing put / get from multiple PUs to the same memory area.
By providing a write / read prohibition flag to the memory area secured for ut / get and allowing the flag to be controlled by the user program, the user can write / read to / from the other PU in the memory area. Achieved by trying to ban.

In order to allow the user to detect duplicate writing and reading in the same memory area,
This is achieved by notifying the user of the issue of put / get to the memory area in which the write / read prohibition flag is set.

[0024]

DESCRIPTION OF THE PREFERRED EMBODIMENTS The details of the present invention will be described below with reference to the drawings.

First, a specific example of the mounting method of the present invention will be described with reference to the drawings. FIG. 1 shows an overall configuration diagram of the present invention. 1
Reference numerals 01 and 102 denote PUs, 103 and 104 are their CPUs, and 105 and 106 are memories. 107 is a communication path connecting these PUs. The number of PUs is actually arbitrary, but a parallel machine composed of two PUs is shown here for the sake of explanation. Reference numerals 108 and 109 denote the OS (operating system) of each PU. When executing the user program, the program is loaded on the memory of each PU (110, 111). The user program is linked with the message passing library (114, 115) of the present invention in advance. In the user program, it is possible to provide a memory area (122, 123) that can be read and written by another PU by remote memory transfer. Further, at the same time when the execution of the parallel program is started, the put / get daemon process (112, 11
3) is activated for each PU. In the message passing library, special routines (interrupt handlers) 120 and 121 activated by an interrupt request from the put / get daemon, and a window information table (124, 124) storing management information of a put / get memory area. 125) is provided. In the interrupt handler, the put that handles the interrupt for the put request
Handler and g that handles interrupts for get requests
There is an et handler.

Of the above components, the message passing library and the put / get daemon are the components that characterize the present invention. Hereinafter, these two components will be described in detail.

(Interface of Message Passing Library) The message passing library (114, 115) in the present invention will be described. The message passing library is a group of functions for executing message passing through the put / get daemon process by calling from the parallel program of the user.

The function interface of the message passing library will be described below. In the present embodiment, the function interface is constructed based on the above-mentioned MPI-2 specifications and by making necessary changes. Actually, the function name, the argument name, etc. are arbitrary and do not necessarily have the same specifications as those described here.

(1) Init () The interface of this function is the same as that of MPI described above.

(2) RMC_Malloc (base,
size, counter, counter_s
access, id) A function that secures a put / get window on its own PU. Arguments base, size, count
The meanings of r and id are the same as in the case of MPI described in the section of the related art. The counter_success is a counter newly provided in the present invention, and its usage will be described later.

(3) Get (origin_addr,
origin_size, target_ran
k, id, incr) This function interface and the meanings of the arguments are the same as the above MPI.
Is the same as

(4) Put (origin_addr,
origin_size, target_ran
k, id, incr) This function interface and the meanings of the arguments are the same as the above MPI.
Is the same as

(5) Set_counter_thre
hold (id, count) This function interface and the meaning of the arguments are the same as the above MPI.
Is the same as

(6) Post_handler (id,
(count) This function interface and the meaning of the arguments are as described above
Is the same as

(7) Window_lock (id) This function and the following Window_unlock function are characteristic of the present invention. When this function is called from the user program, put / get is prohibited for the window corresponding to the window identifier specified by the argument id. This operation is called window locking. The put / get operation for this window cannot be performed until the next Window_unlock function is called for the same window. When a put operation is performed on the locked window, the message is discarded. When the get operation is performed on the locked window, the message is not read and an error code is returned as the return value of the get function.

(8) Window_unlock (id) This function cancels the put / get prohibition of the window for the window identifier designated by id. This operation is called unlocking the window.

(Operation of message passing library)
Hereinafter, a method of realizing each of the above functions in the remote memory data transfer control method of the present invention will be described.

(1) Operation of Init When the initialization function of the message passing library is called from the user program, the window information table shown in FIG. 2 is displayed in the memory area of the library (10 in FIG. 1).
5, 106). The window information table includes a window identifier column, a window start address column, a window end address column, a counter value column, a successful counter value column, a counter upper limit value column, and a flag indicating a window lock state (general Anything that can hold this information in)
Field. Then, each column of the generated table is initialized. As the initial value, 1 is used only for the counter upper limit value column and 0 is used for all other columns. Since the user calls the initialization function from all PUs as described above, the window information table is also created on all PUs.

(2) Operation of Rmc_malloc Function FIG. 3 shows the operation when the window generation function Rmc_malloc is called. First, the start address buff and the length s of the window given as the arguments of the function
Secure window memory using size (30
1). Scan the id column of the window information table and find the column whose id is 0 (initial value) (3
02). The line number of that column is adopted as the window identifier and stored in the corresponding column (303). Next, the address given by buff is stored in the column of the head address of the window, and the value of buff + size is stored in the window end address (304, 30).
5).

The counter value, the maximum counter value, and the lock state flag remain unchanged as initial values.

(3) Operation of Put Function Next, the operation when the Put function is called will be described. FIG. 4 shows the flow of processing. First, pu on the partner PU
A short message (put request) is sent to the t / get daemon to notify that a put request has been issued. Then, the identifier of the destination window and the increment value given as the arguments of the function are also used as the argument target.
Put / get on the partner PU specified in _rank
Send to the daemon (401). (The operation of the put / get daemon will be described later.) This transmission is a normal send.
Use a function. After the transmission, it waits for the recognition signal (ack) from the daemon and blocks (402). ack
If is received, the or
The contents of the transmission buffer indicated by igin_addr and origin_size are transmitted (403). This transmission is also performed by the send function. When all the contents of the send buffer have been sent, return to the user program.

(4) Operation of Get Function Similarly, the operation when the Get function is called will be described with reference to FIG. First of all, put / g on the other party's PU
A short message (get request) is sent to the et daemon to notify that a put request has been issued, and then the identifier of the destination window and the increment value given as the arguments of the function are also used as the argument target_ra.
It is transmitted to the put / get daemon on the partner PU designated in nk (501). This transmission is a normal send
Use a function. After the transmission, the receive function is issued to the daemon to wait for the arrival of data. The received message is the argument origin_addr
And store in the receive buffer specified by origin_size (502). When all the contents are stored in the receive buffer, return to the user program.

(5) Set_counter_thre
Operation of the hold function When this function is called, it searches the window information table of its own PU (Fig. 2) for the row with the identifier specified by the argument, and specifies it in the column of the counter upper limit value of that row by the argument. Stores the counter upper limit value.

(6) Operation of Post_hander function When this function is called, the window having the identifier specified by the argument is searched from the window information table of its own PU (FIG. 2) and the handler column of that row is searched. Stores the pointer of the handling function specified by the argument.

(7) Operation of Window_lock Function When this function is called, the window having the identifier specified by the argument is searched from the window information table of the own PU (FIG. 2), and the lock status flag ( The write / read prohibition flag) is turned on.

(8) Operation of the window_unlock function When this function is called, the window having the identifier specified by the argument is searched from the window information table of its own PU (FIG. 2), and the lock state flag ( The write / read prohibition flag) is turned off.

The above is an example of the method of realizing each function in the remote memory transfer control system of the present invention.

(9) Operation of put handler In the message passing library, in addition to the above-mentioned function group called by the user, put / g activated by interruption from the put / get daemon process
There is an et handler. The operation of the put handler will be described with reference to FIG. When the interrupt is accepted, the process shifts to a reception waiting state from the put / get daemon process, and the window identifier and the increment value of the counter are received (701). When it receives an identifier, it uses it to display the window information table on its own PU (Fig. 2)
Is searched and the corresponding counter is incremented according to the increment value received. Also, the column of the lock flag is checked to see if the window is in the locked state (704). If it is not locked, ack is returned to the put / get daemon process (702), then the message body sent from the put / get daemon process is received and stored in the window (703). Further, the value of the corresponding success counter is incremented according to the increment value (706). Put / g if locked
A nack is returned to the et daemon process (705). Finally, the counter value is compared with the counter upper limit value, and if the counter values are equal or larger, the counter is cleared and control is transferred to the corresponding user-defined handler (70
7). (10) Operation of get handler The operation of the get handler will be described with reference to FIG. When the interrupt is accepted, the process shifts to a wait state for receiving from the put / get daemon process and receives the window identifier (801). When it receives the identifier, it searches the window information table (FIG. 2) on its own PU,
The column of the lock flag is checked to see if the window is in the locked state (804). If it is not locked, ac to the put / get daemon process
k is returned (802), and then the message body stored in the window is transmitted to the put / get daemon process (803). Put if locked
/ Nack is returned to the daemon process (80
5). Finally, compare the counter value with the counter upper limit value,
If the counter values are equal or larger, the counter is cleared and control is transferred to the corresponding user-defined handler (807).

(11) Detection of put / get for locked window In the present invention, when a message is put / get in a locked window for some reason, it is detected as follows. be able to.

For the get function, the get of the get destination
When the handler returns nack, put / get
The daemon process returns an error code to the issuer of the get function (619). Therefore, the user can get
When the return value of the function is an error code, it can be detected that get is issued to the locked window.

Since the put function returns immediately after sending a message to the partner PU, it cannot detect an attempt to write to the window locked by the return code. However, the put handler increments both the success counter and the counter if the put succeeds, but does not increment the success counter if the put does not succeed. Therefore, the user can detect that the locked window is put by comparing the two values in the completion handling function of the put function. That is, when put is performed on the locked window, the value of the success counter should be smaller than the value of the counter.

(Put / get Daemon Implementation Method) Next, put / get in the remote memory transfer system of the present invention will be described.
An example of a method for implementing the get daemon will be described with reference to FIG.

The put / get daemon is normally in a blocked state waiting for a put / get request from a user program of any PU (601). When a put / get request is received by a put / get function call, it branches depending on whether it is a put request or a get request (602), and the processing corresponding to each is started. If it is a put request, first, the window identifier and increment value transmitted are read and stored (603),
ack is returned to the put request source program (604). Next, the message body transmitted from the put request source is received and stored (605), and when all the messages are received, an interrupt is generated to the user program on the own PU (606). (This interrupt calls the put handler on the user program side, and waits for reception.) The daemon sends the window identifier stored in 603 to the user program, and sends an affirmative response (ack) or negative response. The process branches after waiting for (nack) (610). When ack is received, the window is not locked, so 605
The message body stored in step 1 is transmitted to the user program, and the process ends. If you receive a nack,
Since the window is locked, the message is discarded and the processing ends. On the other hand, when the process branches to the get request at 602, the window identifier is received from the requesting PU (612), and the user program on the own PU is interrupted (613). (This interrupt calls the get handler on the side of the user program and waits for reception.) The daemon sends the window identifier stored at 612 to the user program,
The process branches after waiting for an affirmative response (ack) or a negative response (nack) (618). When ack is received, the window is not in the locked state, so a message is sent from the get processing handling function of the user program. This is stored, transmitted to the get request source, and the processing ends (616, 617). When the "nack" is received, the window is locked and the message is not sent, so an error code is returned to the get request source (619).

The above is an example of the method for implementing the put / get daemon.

[0055]

According to the remote memory transfer control method of the present invention, a put using a message passing library is put.
In message communication of the / get system, put / ge
The memory area for t can be locked and unlocked from within the user program. As a result, the user can prevent data from multiple PUs from being overwritten in the put / get memory area, and illegal data can be read out, and message communication by the put / get method can be further improved. You can do it safely.

Further, according to the remote memory transfer control method of the present invention, when an erroneous put / get is made to the locked memory area for some reason, this can be detected. As a result, the user can incorporate an appropriate error recovery into the program, and can create a highly reliable program using the put / get method.

[Brief description of the drawings]

FIG. 1 is an overall configuration diagram of an embodiment of the present invention.

FIG. 2 is an explanatory diagram of a window information table.

FIG. 3 is an operation explanatory diagram of a window generation function.

FIG. 4 is an operation explanatory diagram of a put function.

FIG. 5 is an operation explanatory diagram of a get function.

FIG. 6 is an operation explanatory diagram of a put / get daemon process.

FIG. 7 is an operation explanatory diagram of a put handler.

FIG. 8 is an operation explanatory diagram of a get handler.

[Explanation of symbols]

 101, 102. . . Element calculator 103, 104. . . CPU 105, 106. . . Memory 107. . . Communication paths 108, 109. . . Operating system 110, 111. . . User program 112, 113. . . put / get daemon process 114, 115. . . Message passing library 120, 121. . . put / get interrupt handler 122, 123. . . A window for put / get.

Claims (3)

[Claims] 1. A data transfer control method in a parallel computer, comprising a plurality of computers connected by a communication path, wherein the computers specify a memory area of a data transfer destination computer to transfer data. In the calculation, an arbitrary number of memory areas in which data can be read and written from a program executed on another computer are specified from the program executed on the own computer, and a plurality of the specified plurality of specified memory areas are specified. For each of the memory areas, hold information indicating that reading and writing of data from a program running on another computer is prohibited, and control the information from the program running on its own computer. By prohibiting reading and writing of data in the memory area, the data in the parallel computer is characterized by Transfer control method. 2. Among the designated plurality of memory areas, a memory area for which reading and writing of data from a program executed on another computer is prohibited is executed by another computer. The error is notified to the program on the other computer when the reading of the data is requested by the existing program.
A data transfer control method in the described parallel computer. 3. A memory area, of the specified plurality of memory areas, for which the reading and writing of data from a program executed on another computer is prohibited, is executed on another computer. When the writing of data is requested by the program, the computer discarding the data notifies the program executing on the computer of the discarding of the data. A data transfer control method in a parallel computer according to claim 1.