JPS6339038A - Process synchronizing method - Google Patents

Abstract

PURPOSE:To decrease the past state value to be stored in a process by circulating the token ownership among plural processes that proceed their processings with mutual exchange of message and rolling back the ownership to a stage preceding by a single token cycle by detecting a fault in a single token cycle. CONSTITUTION:Each process receives a token T via a control block 100 and decides via a control block 101 whether its own process is equal or not to a process having the next token ownership. If so (YES), it is decided that the abnormality exists. In such a case, a token owner process turns the value of a time stamp into the value older by a single token cycle via a control block 107. Simultaneously, a system state variable is also set its past state to set a roll-back processing request for the request of a retrial.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to a method for synchronizing processes in a system in which a plurality of processes proceed with processing while exchanging messages with each other.

[Prior art and its problems]

There are broadly two types of process synchronization methods in a system where multiple processes proceed with processing while exchanging messages with each other. One is a time-independent (Tinge-Independent) type process synchronization method, and the other is a time-independent (Tinge-Independent) type process synchronization method.
This is a process synchronization method of the me-Dependent type. Here, a process is considered to be one executing program unit. A time-independent process synchronization method synchronizes processes between the sender and receiver by sending a message and receiving acknowledgment information (ACK) for the message. This method is a typical message exchange type process synchronization method. However, there are problems such as difficulty in recovering from failures and inconsistencies in command execution in multiple processes.In cases where this inconsistency occurs, For example, consider the following example.Now consider a distributed database system for making airline seat reservations.Process A
(User A) and Process B (User B) are attempting to access distributed databases X and Y almost simultaneously and make seat reservations. Here, the distributed databases X, Y
Assume that information indicating exactly the same seat reservation status is stored in In this case, the order of messages from processes A and B arriving at databases X and Y cannot be uniquely determined due to variations in transmission path delay or processing time. That is, it may happen that the data arrives at database X in the order of A and B, and the data arrives at database Y in the order of B and A. At this time, if only one seat is available, database X will give a seat to user A, database Y will give a seat to user B, and information indicating the same seat reservation status should originally be stored. Different information is entered into the database, resulting in inconsistencies.

Next, the time-dependent process synchronization method is described in NCM Transactions on Programming Languages and Systems, Volume 6, Number 2. April 1984 (A CM T
transactions on Pro3ram+s5
-1n Languages and Systems
, Vol. 6. Na2. Lampot (April 1984).

“Using Time Instead of Timeout for Fault-Tolerant Distributed Systems” by L.
In5tead of Timeout for Fa
Ultimate-tolerant Distributed
5yste+ms), each process has a clock that points to almost the same time, and execution of commands to send and receive between processes is performed based on this clock.

That is, the above-mentioned transmission/reception or command execution is started at regular time intervals. The principle of this operation will be explained using FIG. In the figure, the horizontal axis indicates time t. At times T, T+Δ, and T+2Δ, each process starts sending and receiving messages and executes commands. Here, Δ is a value that is set in advance in the system and is sufficient time for message transmission and reception to be completed within that time. In the figure, process 1 is shown between time T and T+Δ.
and process n are message c1 and message C, respectively.
An example is shown in which all of Here, in process 2, message C1 is received first, followed by messages c, . However, in process 3, message Cn is received first, followed by message CI. In such a case, if the time-independent process synchronization method is used, process 2 executes C, , C, in the order, and process 3 executes C, , C,
, C, are executed in this order, resulting in a processing contradiction as described earlier. However, in the time-dependent process synchronization method, command execution waits until the next timing, that is, time T + Δ, and then executes all messages received during Δ at once. By providing all processes with a rule that commands are executed starting from the process with the lowest number, it is possible to have all processes execute commands in the order of C1 and C, and consistent processing can be achieved. In addition, even when a failure occurs, all processes have synchronized clocks in the time dependence 1~ type process synchronization method, so it is possible to control all processes to return to a consistent state at a certain absolute time. Easy to do. Here, messages that cannot be received within 6 hours, that is, delayed messages, are discarded. This delayed message can be easily detected by adding a time stamp to the message. The phenomenon at this time is equivalent to the occurrence of a failure, and recovery control is performed. By the way, in this time-dependent process synchronization method, it is necessary to precisely adjust the clocks possessed by each process so that the absolute times indicated by each clock are almost equal. That is, the difference between each clock must be made sufficiently small compared to Δ. If this condition is not met, it will be necessary to make Δ very large, and the efficiency of the system will be greatly impaired. However, adjusting this clock becomes difficult when taking into account failures in transmission paths, variations in delay, etc.

[Means for solving problems]

According to the present invention, among a plurality of processes that proceed with processing while exchanging messages with each other, only one process has ownership of a token, and the ownership of the token is transmitted within the plurality of processes at a certain time interval. A logical token ownership circular loop is formed, that is, the process that has the token ownership sends the token to all processes after the specified period of time has elapsed, and transfers the token ownership to the next process. The time it takes for token ownership to be handed over from the first process and returned to the first process is called the token cycle, and each process immediately sends a message upon receiving the token. Starts execution of the command in the received message, and the process that owns the token determines whether the system status is normal or abnormal, and if an abnormality is detected in the system status, all processes are returned to the state from one token period ago. or detect an abnormality in the system status and
If no abnormality in the system state is detected within the token period, return all processes to the state one token period ago, detect an abnormality in the system state, and detect an abnormality in the system state within one token period. If so, use a process synchronization method that returns all processes to the state they were in when the previous error was detected, and each process performs failure recovery by retransmitting messages and re-executing received commands. Obtainable.

[Principle of the invention]

The principle of the method of the present invention will be explained using FIGS. 2, 3, and 4. FIG. 2 shows a method of passing tokens that determines the timing of message transmission in each process and the timing of command execution in a received message. The token ownership process that owns the token moves sequentially in time as shown in the figure. In the figure, processes 200 (1) to 200 (6) constitute all processes, arrows indicate the direction of movement of token ownership, and processes with black circles are token ownership processes at a certain time. As described above, the token-owning process issues tokens to all processes in order to start the processing of each process, and transfers token ownership to the next process. This token ownership is held by only one process at a given time. A timing chart of the operation of the present invention is shown in FIG. In the figure, the horizontal axis indicates time t.

Further, the token delivery interval Tp is a value set in advance in the system, and is sufficient time for the token transmission/reception and message transmission/reception processing to be completed within that time. In this figure, process 1 is the token owning process in the first cycle, and transmits a token TK1 indicating the start of the second cycle. process 2 to process n
When the token TKI is received, message sending and receiving command execution are started. In this example, process 1 and process n transmit messages C1 and Cn, respectively, in the second period. These messages reach all processes within the interval Tp. In the second cycle, token ownership follows a predetermined order, eg, to process 2 in this example. Therefore, the token TK2 indicating the start of the third cycle is sent from process 2 as shown in the figure, and when each process receives the token in the third cycle, the messages C1 and C,l sent in the second cycle are executed. be done. For example, by setting a rule for all processes to execute received commands starting from the one with the lowest sent process number, it is possible to have all processes execute commands in the order of C, C, and so on. Concurrency control can be easily realized. When each process receives a token, for example, in the third period in the figure, the command in the message sent in the second period is executed, and the command in the message sent before the second period and arriving after a long delay is executed. , is checked by looking at the timestamp value, and is rejected without being executed. By doing this, the consistency of the concurrency control described above can be maintained, but process failures will occur. That is, this rejection operation for a delayed message causes a phenomenon equivalent to, for example, a message being lost or a failure occurring in a process. Next, a control function for such a process failure will be explained using a diagram.

The token ownership process has a system failure detection/recovery control function as well as control for sending and receiving tokens as described above. This system failure detection/recovery control will be explained using FIG. 4. Figure 4 (a>
indicates the transition of the timestamp ts. That is, in this figure, the timestamp value increases with time from T1 to T16.

Now, it is assumed that the total number of processes N is 5 and that a process failure is detected at time ts=Tg. At this time, the state returns to the state one token period ago, so since the total number of processes is 5, the state is rolled back (roll-back) to the state of tS=T4.
k) Do. Note that the token cycle is the time it takes for token ownership to be sequentially transferred from the first process until it returns to the first process. Moreover, this rollback means returning the timestamp value and system state to the past state and causing a retry.

In this state, the process is retried from t,=T4, and then 5=
Assume that a process failure is detected again at T7. In the invention described in claim (1), since the state is rolled back to the state one token cycle ago, the state returns to ts=T2,
In the invention described in claim (2), since the rollback was performed within one token cycle in the past, the state returned to the previously rolled back state, that is, the state of ts=T4 in this example, and the retry is performed. It will be done. Regarding the failure occurrence example described above, FIG. 4(b) shows the recovery state transition corresponding to claim (1) of the present invention, and FIG. 4(c) shows the transition of the recovery state corresponding to claim (1) of the present invention. The recovery state transition corresponding to 2) is shown. In the method of the present invention, by circulating token ownership among all processes, each process can always become a uniquely owning process once within one token cycle. Since the token ownership process checks the system status to detect failures, this cycle of token ownership means that failures can be reliably detected within one token cycle after a failure occurs. It becomes possible to obtain a highly reliable process synchronization method.

[Example] FIG. 1 shows an example of the present invention. FIG. 1(a) shows the processing algorithm of the token ownership process in the embodiment of the invention described in claim <1). In each process, a token T (t s
, St, CNT), the control block 101 determines whether the own process is the next process to have ownership of the token.

Here, the time stamp ts in the token increases by 1 each time token ownership is transferred during normal operation. Also, St is a system state variable, and CNT
is the control variable. The determination in control block 101 is YE.
In the case of S, the processing of the process having the token ownership is started, and a system abnormality is detected by checking the above-mentioned timestamp and system state variables in the control block 102. If there is no abnormality in the system, that is, if the determination result in control block 102 is No, then message sending command execution is started in control block 103, messages are received from other processes, and system state variables are is updated. The series of processing in the control block 103 is the same for both the token possessing process and the general process, and is called token interval processing. Once these token interval operations are finished,
The token owning process increments the value of the timestamp by one at control block 104, updates the system state variable to the new value, and also places the value NULL in CNT. In control block 105, when it is time to transfer the token to the next 1-kun controlling process, i.e., after receiving the token from the previous token owning process and the interval Tp has elapsed, the token owning process transfers the token to control block 106.
sends a token with these values as variables to all processes and relinquishes ownership of the token. Of course, the token contains a variable that indicates the address of the next token-owning process, so of all the processes that received this token, the process designated as the next 1-hook-owning process receives the token for the next token interval process. It executes the algorithm of the owning process. If a system abnormality is detected in control block 102, that is, if the detection result is YES, the token owning process returns the timestamp value to N in control block 107, where N is the total number of processes. So the timestamp is N
(Reverting to a timestamp value that is one token cycle past), sets the system state variable to a value that is one token cycle past, and requests the CNT to return to the past state and retry, that is, roll pack. Set a processing request command. Thereafter, in control block 105, when the time Tp has elapsed, tokens having these variables are sent to all processes.

FIG. 1(c) shows a processing algorithm for the token ownership process in the embodiment of the invention set forth in claim (2). The inventions recited in claims (1) and (2) differ only in the operation upon detection of a system abnormality, so only this operation will be described. Figure 1 (c
) is executed in place of the control block 107 when a system abnormality is detected in the control block 102 of FIG. 1 (a). The control block 12 checks whether the detection has returned to the past state and a retry has been performed.
It is done with 0. If not, the same process as in control block 107 in FIG. The state at that time is set to a system state variable, and the N' roll pack is stored in CNT. Since the system state should have been normal at the time of the previous rollback, it is possible to return to the normal past state with this process as well.

FIG. 1(b) shows token interval processing in a process other than the token owning process. As a process when the determination in the control block 101 is No, first the control block 110
Checks whether the variable CNT in the token is NULL or a role pack. If it is NULL, that is, if the determination result of control block 110 is YES, message sending and command execution are started in control block 111, commands received from other processes are executed, and system state variables are updated. It will be done. Thereafter, the control block 112 increments the time stamp value by 1, and the process moves to the control block 100 to wait for the next token to be received. Further, if the determination result of the control block 110 is NO, the control block 113 stores the time stamp value and the system state.
Rollback processing is performed to return to the past normal state value indicated by the variable in the token.

〔Effect of the invention〕

According to the present invention, there is no need to resynchronize locks, which is necessary in conventional time-dependent process synchronization methods, and a practical process synchronization method can be obtained. Furthermore, concurrency control can be easily performed. Furthermore, since token ownership is circulated, it is possible to reliably detect a failure within one token period after the failure occurs, and highly reliable process synchronization is possible. By storing the past state in each process, it is possible to rollback when a failure is detected, and the fact that a failure can be detected within one token cycle after it occurs is possible at the time one token cycle ago. Since a more normal state is guaranteed, failure recovery is possible by rolling back to this point (one token cycle earlier) and retrying the process. In addition, if a system failure is detected and a rollback is performed within the past 1)--kun period, each process is It is also possible to reduce the amount of past states to be used.

[Brief explanation of drawings]

FIG. 1 (a>, (b), (c) is a flowchart showing the algorithm in the embodiment of the present invention, FIG. 2 is an explanatory diagram showing the circulation of token ownership for realizing the method of the present invention,
FIG. 3 is a timing chart showing the principle of the method of the present invention, FIG. 4 is a state transition diagram showing the failure recovery method in the method of the present invention, and FIG. 5 is a diagram showing the principle of the conventional time-dependent process synchronization method. This is a timing chart. Tp... (token) delivery interval, TKI...
Token, ts...Time stamp, T1-T16.
...Timestamp value, N...Total number of processes, S,...
...System state variable, CNT...Control variable, 101
〜107.111〜113,120.121...Control block. I Seki) Ta/Tl! J (Fig. 1 (C) β 1 0 Teeth Eye 1- - Voice H Mouth) Force Deaf)-)-Kedo)! l! )-)--H

Claims (2)

[Claims] (1) Among multiple processes that proceed with processing while exchanging messages with each other, only one process has ownership of the token, and the ownership of the token is passed between the multiple processes at regular intervals. The process that owns the token sends the token to all processes after the specified period of time has elapsed, passes the token ownership to the next process, and the process that owns the token sends out the token to all processes after the specified period of time has elapsed. The token period is the time it takes for the right to be passed from the first process to the time it returns to the first process.When each process receives the token, it immediately sends a message and executes the command in the received message. The process that starts execution and has ownership of the token determines whether the system status is normal or abnormal, and if an abnormality is detected in the system status, all processes are returned to the status one token cycle ago, and each process A process synchronization method characterized by performing failure recovery by retransmitting messages and re-executing received commands. (2) Among multiple processes that proceed with processing while exchanging messages with each other, only one process has ownership of the token, and the ownership of the token is passed between the multiple processes at regular intervals. The process that owns the token sends the token to all processes after the specified period of time has elapsed, passes the token ownership to the next process, and the process that owns the token sends out the token to all processes after the specified period of time has elapsed. The token period is the time it takes for the right to be passed from the first process to the time it returns to the first process.When each process receives the token, it immediately sends a message and executes the command in the received message. The process that starts execution and has ownership of the token determines whether the system state is normal or abnormal, and if an abnormality in the system state is detected and no abnormality in the system state has been detected within the past one token cycle. If all processes are returned to the state from one token cycle ago, and an abnormality in the system state is detected, and an abnormality in the system state has been detected within the past one token cycle, all processes are returned to the state they were in when the previous abnormality was detected. A process synchronization method characterized in that processes are returned and each process performs failure recovery by retransmitting messages and re-executing received commands.