JP2767831B2 - Access control method for shared devices - Google Patents

Description

The present invention relates to an access management method for a shared device,
In particular, when the CPU is down, that is, when the CPU is stopped or a failure occurs (hereinafter, referred to as “CPU down”), an access management method of a shared device suitable for smooth backup, and a failure propagation through the shared memory. The present invention relates to an access management method for a shared device that is suitable for prevention of the problem.

[Conventional technology]

For example, in the conventional access management method for a shared memory, when one CPU accesses a certain area of the shared memory, first, access to another CPU is prevented.
Lock and read / update operations are performed, and after completion, the relevant CPU must be able to access the same area by other CPUs only after the lock is released to solve the contention problem. I was

Related to this type of method are, for example, Briggs et al .: “Computer Architecture Architecture”
And Parallel Processing (1984) "(Briggs
et al .: “Computer Architecture and Parallel Proce
ssing ").

[Problems to be solved by the invention]

The above-mentioned prior art uses a CPU accessing a certain memory area.
If the CPU is stopped or a failure occurs, there is a problem that the memory area cannot be accessed by another CPU due to the lock applied by the CPU. In addition, the above conventional technique has a problem that when a CPU accessing a certain memory area runs away and destroys the memory contents of the area, processing of another CPU using data in the area becomes impossible. was there.

Further, a similar problem exists not only in access management to a shared memory but also in overall access management to a shared device.

The present invention has been made in view of the above circumstances, and an object of the present invention is to solve the above-described problem of the related art and to solve a contention problem without locking by a CPU. It is an object of the present invention to provide a device access management method and a shared device access management method capable of preventing the propagation of a failure through the shared device.

[Means for solving the problem]

An object of the present invention is to provide a system including a plurality of CPUs and a plurality of devices, each of the plurality of devices being connected to two or more CPUs, wherein the plurality of devices are grouped into a plurality of groups. Divide and group each
As a dedicated group for each CPU, CPUs that occupy the group
The access right to the group or a device belonging to the group is set to be given to another predetermined CPU only when the device goes down or an abnormality occurs in the connection with the device belonging to the group. An access management method for a shared device, wherein when the shared device is a shared memory, the shared memory is divided into a plurality of areas, and each part of the divided shared memory is assigned to each of the CPs.
As a dedicated area for each U, only when the CPU that occupies the area goes down, the access right to the area is changed to another predetermined area.
While causing the CPU, the internal memory of the plurality of CPUs to have a copy of the shared memory, write the same content to the dedicated area and the copy at the time of memory writing,
At the time of reading, the data in the dedicated area is compared with the data in the copy. If there is a mismatch, it is determined that the contents of the shared memory have been destroyed, and the area is restored based on the copy. Achieved by a shared device access management scheme.

[Action]

Each CPU stores a dedicated area on the shared memory and an area (backup area) that can be accessed when another CPU goes down. During normal operation, each CPU should access only its own dedicated area. Is configured. However, the operation is performed so as to access the area only when another CPU is down and there is an area in which a new access right can be obtained due to the down of the CPU. In addition,
Only after receiving the acknowledgment signal (access right relinquish signal) from all other CPUs, the CPU that has recovered from the down state accesses the shared memory and performs processing by copying the dedicated area and the backup area.

Also, in the normal operation state, the same operation is performed to write both data at the time of writing, and only the content of the internal memory is read at the time of reading. Therefore, even if the shared memory is destroyed by another CPU, there is no problem in normal operation.

〔Example〕

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

FIG. 2 is a system configuration diagram showing one embodiment of the present invention. In the figure, 1 is a shared memory (GM) composed of four blocks connected by a common bus, and 21 to 28 are shared memories 1
80 blocks (M1 to M8) obtained by theoretically dividing each block into two. These small blocks M1 to M8
Contains personalized data for each of the 128 terminals. Reference numerals 31 to 34 denote CPUs (P1 to P4), and these CPUs 31 to 34 are connected to a ring network indicated by 4.

Also, 1024 terminals 5 (51 to 51024) are connected to the ring network 4, and each terminal is configured to be able to communicate with the CPU through this network.

Before describing the operation, some terms are provided. First, an area in the shared memory 1 to which each CPU has an access right is referred to as a “assigned area”. A terminal having the individual correspondence data in the area is referred to as a “terminal in charge”. Further, a dedicated area and a backup area of each CPU are defined as shown in FIG.

The operation of the present embodiment configured as described above will be described below.
The operation will be described according to the operation flow of FIG.

First, a normal operation will be described. At this time,
The assigned area of each CPU is equal to the dedicated area, and each terminal accesses the individual data in the shared memory 1 via the CPU having the assigned terminal and performs a task (steps 81 to 83).

Next, an operation when the CPU is down will be described by taking a case where the CPU (P2) 32 is down as an example. Since the CPUs monitor each other via the network 4, the fact that the CPU (P2) 32 has gone down is known to other CPUs (step 8).
1). Therefore, each CPU checks its own backup area (step 84), and if any is included in the responsible area of the downed CPU (step 85), it includes it in its own responsible area (steps 86 to 86). 87). In the example above, CP
U (P1) 31 is a small block M3, CPU (P3) 33 is a small block
M4 will be added to the area in charge. Thereafter, CPU (P2) 32
Terminals that have been working through, the CPU (P1) 31 or C
Business will be continued via PU (P3) 33. The situation in this case is shown in FIG. In FIG. 4, symbols 61 to 610 indicate the relation of access.

Next, the operation when the CPU (P2) 32 recovers will be described in the above example. As mentioned earlier, mutual monitoring
CPU (P1) 31 that knew that CPU (P2) 32 had recovered or
The CPU (P3) 33 stops access to the small blocks M3 and M4, respectively, and outputs a message (recovery acknowledgment signal) 7 indicating that service can be resumed in steps 88 to 90, to the CP (P3) 33.
Send to U (P2) 32. Only then will the CPU (P2) 32 resume service to the terminal as before. The situation in this case is shown in FIG. In FIG. 5, symbols 61 to 68 indicate the access relation.

Before the failed CPU (P2) 32 recovers,
If another CPU goes down (step 9
1) The same processing (step 84 and subsequent steps) as when the CPU (P2) 32 goes down as described above is performed.

According to the above embodiment, when 1 CPU is down, or when 2C
Even when the PU (for example, the CPU (P2 and P4)) goes down, there is an effect that service to all terminals can be continued. Since the shared memory is used, the access does not slow down even during backup. Actually, it is necessary that the following conditions are satisfied.

(1) The independence of data among each CPU handled by each CPU is high. (2) The data handled by one CPU can be used by other CPUs for service. Next, another embodiment of the present invention will be described. A description will be given based on FIG. The present embodiment corresponds to claim 4.

In FIG. 6, symbols 1,21 to 28,31 to 34,4,51 to 51024
Indicates the same components as those shown in FIG. Each of the small blocks (M1 to M8) 21 to 28 of the shared memory 1 has
Contains personalized data for 128 devices.

The difference from the configuration shown in FIG. 2 is that each of the CPUs 31 to 34 holds a copy of each dedicated area and backup area, and 41 to 44 in FIG. 6 correspond to this. Note that these are called private files (PF) of each CPU, and a terminal in which individual data is placed is called a “possible terminal”.

Hereinafter, the operation of this embodiment will be described with reference to the flowcharts shown in FIGS.

First, a normal terminal service will be described. At this time, the assigned area of each CPU is equal to the dedicated area. A processing request from each terminal is received by all CPUs as a message including a terminal number and processing contents. The operation of each CPU in response to this is as shown in the flowchart of FIG.

If it is a processing request from a terminal in charge and not a terminal in charge (steps 201 to 203), only the PS update processing is performed and no result is returned (step 207). If the terminal is in charge, access is made to both the shared memory (GM) 1 and the PS for comparison, and if there is a mismatch (step 204), the PF
After the corresponding data is copied to the shared memory, predetermined processing is performed on both sides (step 206), and after completion, the result is reported to the terminal (step 210). In FIG. 6,
Terminal with data in small block (M3) 23 of shared memory 1
The flow of the processing request from 51 is represented by reference numeral 71, and the flow of reporting the result from the CPU in charge of the terminal is represented by reference numeral 72.

Next, the operation at the time of CPU down is performed in the same manner as in the previous embodiment.
An example in which the PU (P2) 32 goes down will be described. Since each CPU monitors each other via the network 4,
The fact that the CPU (P2) 32 has gone down is known to other CPUs (step 101). Therefore, each CPU checks its own backup area (step 84), and if any of them is included in the area in charge of the downed CPU (step 10).
8) Include it in your area of responsibility (step 109). In the above example, the CPU (P1) 31 replaces the small block M3 with the CPU (P3)
33 adds the small block M4 to the assigned area.

Thereafter, the terminal that has received the processing result from the CPU (P2) 32 until then receives the processing result from the CPU (P1) 31 or the CPU (P3) 33. The situation in this case is shown in FIG. The flow indicated by reference numerals 71 and 72 in FIG. 6 changes as indicated by reference numerals 73 and 74 in FIG.

Before the CPU (P2) 32 goes down, the shared memory (GM) 1
CPU (P1) 31 or C
The PU (P3) 33 processes the terminal request. In this case, as described above, it is detected that a mismatch occurs in the data of the shared memory (GM) 1 and the PF (step 204), and the destroyed data is Recovery is performed based on the PF (step 206).

Next, the operation when the CPU (P2) 32 recovers will be described in the above example. As mentioned above, mutual monitoring allows the CPU (P
2) The other CPUs that have learned that the 32 has recovered have each inhibited access to the shared memory (step 113), and in step 114, received a message indicating that access to the shared memory has been inhibited by the network (GM access). Suppression message). Only after receiving this from all other CPUs does the CPU (P
2) 32 accesses the shared memory and restores the PF (step 103). In addition, CPUs that are not accessing shared memory
Performs normal terminal services without shared memory access. The operation flow in this case is shown in FIG.

The CPU (P2) 32 sends a message (PF recovery message) indicating that it has returned to the normal operation state to the network (step 105). The other CPUs that receive this,
Start accessing your area again and the system returns.

In FIG. 11, reference numerals 75 to 77 denote access suppression messages, reference numerals 78 to 711 denote data flows from the shared memory to the PF of the CPU (P2) 32, and reference numeral 712 denotes a PF recovery message.

According to the present embodiment, when one CPU is down, or when a specific two CPUs
Even when the CPU (P2 and PS) goes down, the service to all terminals can be continued. In addition, since the shared memory is used, there is an effect that the individual corresponding file in the recovered CPU can be recovered at a high speed.

Next, as shown in each of the above-described embodiments, a unit (CCU) for performing communication control between the CPU and the terminal is provided instead of providing the terminal itself with a network communication function and connecting the CPU and the terminal to the same network. Here is an example of use. In this case,
The CCU is a shared device.

FIG. 12 shows a system configuration diagram in this case. In the figure,
Symbols 1, 31 to 34, 51 to 51024 indicate the same components as those shown in FIG. 2, and 8a to 8h indicate CCUs (communication control units). Although the above-described block shared memory and network are not shown in FIG. 12,
It is assumed that the terminals are grouped into blocks for each of those having the individual correspondence data, and are connected to the CCU for each group. Further, the following terms are defined corresponding to the terms such as “charge area” and “charge terminal” defined in the above-described embodiment.

For each CPU, the CCU connected to the line is
The CCU that returns a processing result in response to the processing request is referred to as a “charged CCU”. "Dedicated CCU", "Backup CC"
U ”is determined as shown in FIG. 13, and this table (allocation table) is assumed to be possessed by each CPU.

The normal operation of the system in this case is as follows. The only CCU that can be assigned to each CPU is a dedicated CCU, and the operation when the other CPU goes down and the operation when it recovers are the same as the operations for the shared memory block described above. That is, at the time of CPU down, each CPU refers to the above-mentioned assignment table and, if the CCU in charge of the downed CPU is included in the available CCU of its own CPU, includes the CCU in the assigned CCU.

The operation of the CCU is as follows. When the CCU accepts a processing request from the terminal, it first receives the signal as the acceptance number and its own CC.
A U number is attached and transmitted to both of the two connected CPUs. Each CPU returns a processing result to the CCU if the received data is from the assigned CCU, and otherwise returns no processing result. In FIG. 12, the flow of a processing request from the terminal 51 is denoted by reference numeral 713, and the flow of a processing result is denoted by reference numeral 714.

Next, the operation when a failure occurs in the line between the CPU and the CCU will be described. As an example, let us consider a case where a failure has occurred in the line between the CPU (P1) 31 and the CCU 8a. In this case, the CPU (P1) 31
It broadcasts a failure information message consisting of its own CPU number and the CCU number of the partner in which a line failure has occurred. The other CPUs receiving this respectively refer to the above-mentioned assignment table,
If the CCU is included in the available CCU of the own CCU, the CCU
Is included in the assigned CCU. In this example, the service to the CCU 8a is performed by the CPU (P4) 34 thereafter.
The flow of the processing result in this case is indicated by reference numeral 715 in FIG.

According to the above-described embodiment, there is an effect that similar service continuity can be maintained without giving the terminal itself a network communication function as in the above-described embodiment, and the system manufacturing cost can be reduced.

It is to be noted that each of the above embodiments is shown as an example, and it is needless to say that the present invention is not limited to these embodiments.

〔The invention's effect〕

As described above, according to the present invention, a shared memory access management method capable of solving a contention problem without locking by a CPU and a shared memory capable of preventing the propagation of a failure through the shared memory This has a remarkable effect that a memory access management method can be realized.

[Brief description of the drawings]

FIG. 1 is an operation flowchart showing one embodiment of the present invention,
FIG. 2 is a system configuration diagram of the embodiment, FIG. 3 is a diagram showing a definition example of a dedicated area and a backup area of each CPU, and FIG.
Diagram explaining the transfer of access rights when 1 CPU goes down,
FIG. 5 is a diagram for explaining the transfer of the access right when the down CPU is recovered, FIG. 6 is a system configuration diagram showing another embodiment of the present invention, FIGS. 7 to 9 are operation flowcharts of the embodiment, FIG. 10 is a diagram for explaining the operation when one CPU is down, FIG. 11 is a diagram for explaining the operation when the down CPU is recovered, FIG. 12 is a system configuration diagram showing still another embodiment of the present invention, and FIG. FIG. 14 is a diagram showing a definition example of a dedicated area and a backup area of each CCU. FIG. 14 is a view for explaining an operation when a one-line failure occurs. 1: Shared memory (GM), 21 to 28: Small block of shared memory 1 (M1 to M8), 31 to 34: CPU (P1 to P4), 4: Ring network, 41 to 44: PF, 5 (51 To 51024): terminal, 7: recovery acknowledgment signal, 71, 73: processing request flow from the terminal, 72 and
74: flow of processing result notification from CPU, 75 to 77: access control message, 78 to 711: data flow, 712: recovery message, 713: processing request flow, 714, 715: processing result flow,
8a to 8h: CCU.

──────────────────────────────────────────────────続 き Continued on the front page (72) Katsumi Kono, Inventor System Development Laboratory, Hitachi, Ltd. 1099, Ozenji, Aso-ku, Kawasaki, Kanagawa Prefecture (72) Inventor Yasuo Suzuki 1099, Ozenji, Aso-ku, Aso-ku, Kawasaki, Kanagawa, Inc. Hitachi, Ltd. System Development Laboratory (72) Inventor Masayuki Orimo 1099 Ozenji, Aso-ku, Kawasaki City, Kanagawa Prefecture Hitachi, Ltd. System Development Laboratory Co., Ltd. (56) References JP-A-1-251158 (JP, A) JP-A-60-101665 (JP, A) JP-A-61-260349 (JP, A) JP-A-55-76466 (JP, A) JP-A-62-264355 (JP, A) (58) Fields investigated (Int) .Cl. ⁶ , DB name) G06F 15/163

Claims (4)

(57) [Claims] In a system having a plurality of CPUs and a plurality of devices, each of which is connected to two or more CPUs, the plurality of devices are divided into a plurality of groups. Each group as a dedicated group for each CPU, belonging to the group or the group only when the CPU occupying the group goes down or an abnormality occurs in connection with a device belonging to the group. If access to the device is
An access control method for shared devices, which is generated in the CPU. 2. An access to a predetermined group of CPUs recovered from the down state or abnormal connection state is started only upon receiving an access right relinquish signal from another CPU having the current access right. The access management method for a shared device according to claim 1. 3. The access management method for a shared device according to claim 1, wherein said device is a shared memory divided into blocks. 4. In a system having a plurality of CPUs and a plurality of devices, and each of the plurality of devices is connected to two or more CPUs, in particular, the device is a shared memory divided into blocks. In some cases, each part of the divided shared memory is set as a dedicated area for each CPU, and only when the CPU that occupies the area goes down, the right to access the area is given to another predetermined CPU. In addition, the internal memory of the plurality of CPUs is provided with a copy of the shared memory, and the same contents are written in the dedicated area and the copy at the time of memory writing, and the data in the dedicated area and the data in the copy are written at the time of reading. Comparing the contents of the shared memory with each other and, if there is a mismatch, determining that the content of the shared memory has been destroyed and restoring the area based on the copy. .