JP2535631B2 - Calling call control method - Google Patents

Description

[Detailed Description of the Invention] [Outline] Regarding a coroutine call control method in a data processing system in which a request is passed between a plurality of coroutines and a coroutine is operated on a plurality of execution bodies for each request, OS exclusive control is performed. For the purpose of providing a mechanism that allows a program to operate simultaneously on different execution bodies without using a function, each request requires an identifier of a coroutine that should process the request and exclusive processing. The serialization identifier assigned to each unit is set, the processing means for connecting to the request queue, and the serialization of the corresponding coroutine activation are performed based on the serialization identifier set in the request by extracting the request. And a coroutine dispatcher for control.

[Industrial applications]

The present invention relates to a coroutine read-out control method in a data processing system in which a request is passed between a plurality of coroutines, and a coroutine is operated on a plurality of execution bodies with a large number of operations for each request.

In a computer system, when operations are performed in a multiplexed manner, exclusive control is generally required to prevent logical conflicts due to conflicting accesses to the same resources used. A technology is required to prevent the deterioration of the response and throughput due to the exclusive control.

[Conventional technology]

FIG. 8 shows an example of a general program execution control mechanism, FIG. 9 shows an example of calling a coroutine, FIG. 10 shows an example of conventional exclusive control, and FIG. 11 shows an example of conventional coroutine execution.

As shown in FIG. 8, the computer operating system (OS) 11 has one central processing unit (CPU).
In order to allocate the above to a plurality of programs A, B, C, there are provided units called executers E1, E2, E3 called tax, thread or process. Execution body E
There are multiple 1, ..., so that each works well, O
S11 controls.

Programs that run under the control of the executable provided by OS11 are structured in a hierarchical structure such as a main program and subprograms. However, it is only in one execution body, and when the programs operating between different execution bodies play the role of one processing control mechanism, they cannot be controlled in the hierarchical structure of the main program and the subprogram. Therefore, there is used a technique of controlling the programs while synchronizing the programs operating in the position of the main program. A program controlled in this way is called a coroutine.

An example of calling this coroutine is shown in FIG. In FIG. 9A, coroutine a calls coroutine b, and coroutine b calls coroutine c. In FIG. 9B, the coroutine d is the coroutine e,
f, g are called, coroutines e, f call coroutine h, and coroutine g calls coroutine i. As described above, it is possible to call one coroutine from a certain coroutine or a plurality of coroutines.
Further, these coroutines can operate on different execution bodies or the same execution body.

The difference from the subroutine is that in the case of a coroutine, the execution body may be different depending on the calling relationship, and normally, because control does not return, a parent-child relationship does not occur. Such a coroutine technique is applied when, for example, input does not need to be controlled by one executing unit until a response is returned.

By the way, when a plurality of programs use the same computer resource, exclusive control by acquiring and releasing a lock is required. FIG. 10 shows an example of the exclusive control.

The program A having the same contents operates on different execution bodies E1 and E2. This program A locks the virtual area R. For example, it is assumed that the execution unit E1 acquires the lock first and is in the process of the section a. The execution body E2 receives control from the OS and tries to acquire the lock, but since the execution body E1 has already acquired the lock, the execution body E2 is in a waiting state until after the section a. The OS passes control to another execution unit E3.

Even under the control mechanism of coroutines, similar exclusive control is required. An example will be described below with reference to FIG.

As shown in FIG. 11 (a), the coroutine module 00
From 0c, 000d, 000e, coroutine module 000a
Suppose there is a request, a request, and a request. It is also assumed that there is a request from the coroutine module 000f to the coroutine module 000b.

Here, it is assumed that the two execution bodies E1 and E2 are executable. First, the execution unit E1 picks up the request, operates the coroutine module 000a, and performs the processing. If necessary, lock a resource. Similarly, the executing body E2 picks up the request and operates the coroutine module 000a, but uses the same resource,
As shown in Figure 11 (b), the lock release waits
Is stopped by.

As described above, conventionally, the request and the request may be processed by the coroutine module 000a on different execution bodies. Therefore, in order to process them in order, the exclusive control function by the OS lock must be used. There wasn't. Therefore, within the range of request processing serialization, even if there are multiple execution bodies, only one execution body operates. Also, the processing order by the lock is
It was necessary to program on the side that created the coroutine module.

[Problems to be Solved by the Invention]

If the same program operates in different execution bodies, even if the coroutine technique is used, the operations cannot be guaranteed unless the OS lock function is used, such as when updating the same virtual area. However, when the exclusive control function of the OS is used, the range in which exclusive programs run in parallel is limited, and there is no point in extending the exclusive range to run programs in different execution bodies. There's a problem. That is, there is a problem that the execution multiplicity of the execution body cannot be increased.

The present invention solves the above problems and provides a mechanism that allows programs to run simultaneously on different execution units, avoiding problems related to access conflicts, etc., without using the exclusive control function of the OS. Is intended.

[Means for solving the problem]

 FIG. 1 is an explanatory view of the principle of the present invention.

In FIG. 1, 10 is a processing unit including a CPU and memory, 11 is an operating system (OS), 12-1,
12-2 is an execution unit that is a unit of CPU execution right allocation, 13-1,
13-2 is a coroutine dispatcher that analyzes requests and activates coroutines, 14A to 14D are coroutine modules that consist of programs that operate as coroutines, 15 is a coroutine scheduler that queues requests to call other coroutines, and 16 is A request queue to which a processing request to each coroutine is connected, 17 is a queue terminal of the request queue 16, and 18 is a request which is call information when the coroutine module calls another coroutine module.

A coroutine module in which the program that performs the desired processing is distinguished by a coroutine identifier according to its contents.
Prepared as 14A, 14B, ... These coroutine modules 14A, ... Can operate on any of the execution bodies 12-1 and 12-2.

When a coroutine module, such as the coroutine module 14A, calls another coroutine module, the call information is set as the request 18. After that, the coroutine scheduler 15 is called. The coroutine scheduler 15 connects the request 18 to the request queue 16 corresponding to the callee coroutine module group.

In this request 18, in addition to the coroutine module identifier for identifying the coroutine module, the serialization identifier given to each unit that requires exclusive processing is set by the requesting coroutine module. There is.

The coroutine dispatchers 13-1 and 13-2 are directly called by the operating system 11 and
-1 and 12-2 are programs that call and operate coroutine modules. Adopting a reentrant structure, each executing body 12-1 and 12-2 operates similarly.

The coroutine dispatchers 13-1 and 13-2 take out the request from the request queue 16 and obtain the corresponding coroutine module 14B or the like from the coroutine identifier. At this time,
If the serialization identifier is set in request 18,
Check if there is a coroutine module that works with the same serialization identifier. If there is a coroutine module that operates with the same serialization identifier, the dispatch of the request 18 is stopped and the processing for the next request 18 is started for serialization control. If no coroutine module operates with the same serialization identifier, that coroutine module is activated.

This serialization control may be performed between coroutines or may be performed only for one and the same coroutine.

The coroutine modules 14A, ... Are returned to the coroutine dispatchers 13-1, 13-2 on the same executing body 12-1 ,. The coroutine dispatchers 13-1 and 13-2 again request the request 18 from the request queue 16.
, And call the coroutine module while performing serialization control in the same way. This process is repeated until there are no more requests 18 in the request queue 16.

[Action]

Coroutine modules that must exclusively use the same resource are assigned the same serialization identifier in advance when designing the coroutine module. And
When requesting processing to this coroutine module, the serialization identifier is set in the call information.

As a result, the coroutine dispatcher checks whether or not the coroutine module having the same serialization identifier is operating and performs serialization control. Therefore, even if the exclusive control function provided by the OS is not used, resource access conflicts, etc. Can be prevented. Along with this, it becomes possible to substantially improve the execution multiplicity of the execution body because the execution body is not kept waiting for a long time due to the lock release wait or the like.

If the serialization identifier is set in the request, the following two methods can be selected. Which function is to be used is statically determined when the control program is initialized.

-If no coroutine is operating with the same serialization identifier, call the coroutine for the request. All coroutines are serialized if they have the same serialization identifier. This is called an inter-coroutine serialization function.

-If the same serialization identifier is detected, detect if a coroutine with the same coroutine identifier is running.
If it is a different coroutine, call the coroutine for that request. This is called a serialization function in the coroutine.

〔Example〕

FIG. 2 is an explanatory view of an embodiment of the present invention, FIG. 3 is a time chart of the embodiment of the present invention, FIG. 4 is a management table relationship diagram used in the embodiment of the present invention, and FIG. 5 is an embodiment of the present invention. 6 shows the processing flow of the coroutine scheduler according to FIG. 6, FIG. 6 shows the processing flow of the coroutine dispatcher according to the embodiment of the present invention, and FIG. 7 shows a modification of the processing flow of the coroutine dispatcher shown in FIG.

In FIG. 2, threads 20-1 and 20-2 are units to which the CPU execution right is passed by the OS. Hereinafter, these threads 20-1 and 20-2 are referred to as execution bodies E1 and E2.

As shown in FIG. 2, the coroutine modules 14C, 14D,
Requests to call coroutines from 14E and 14F,
,,, A coroutine identifier (id) for identifying the coroutine module that processes the request and a serialization identifier (id) are set in these requests as shown in the figure. On the other hand, the coroutine dispatcher 13 performs the following processing on the execution unit E1 or E2.

(1) A request is fetched from the request queue 16 under the execution body E1. Since the coroutine module is not operating with the serialization id corresponding to this request, coroutine id = 000a
Call the coroutine module 14A.

(2) A request is fetched from the request queue 16 under the execution body E2. The coroutine module is operating with the serialization id corresponding to this request.
Connect to the queue of the thread with id = 000a. The request is retrieved from the request queue 16 again. Serialization id (= 0002),
Since it is different from the one currently operating in the execution unit E1 (= 0001), the coroutine module 14A with the coroutine id = 000a is called.

(3) Under the execution body E1, the coroutine module 14A
Completes the processing for the request and returns to the coroutine dispatcher 13. The coroutine dispatcher 13 checks whether there is a request for this coroutine module. Since there is a request, call coroutine module 14A again.

(4) Under the execution body E2, the coroutine module 14A operating with the serialization id = 0002 finishes the processing for the request and returns to the coroutine dispatcher 13. The coroutine dispatcher 13 checks whether there is a request for this coroutine module. Request queue because there is no request
Take the request from 16. Since the coroutine module is not running with the corresponding serialization id, coroutine id = 00
Call coroutine module 14B at 0b.

A time chart of the operation by the above control is as shown in FIG. Since processing for different serialization id requests is performed on the execution bodies E1 and E2, there is no waiting time such as waiting for lock release, and as is clear from comparison with the conventional example shown in FIG. Execution efficiency improves.

In this embodiment, a management table as shown in FIG. 4 is used to manage the threads that are execution bodies.

One thread group management table 30 is created for one thread or a plurality of threads. When configuring with multiple threads, as shown in Fig. 4, each thread management table
31-1, 31-2, ... are sequentially connected in a ring shape. A request queue 16 is provided for this thread group management table 30.

The thread management tables 31-1, 31-2, ... Are created corresponding to the threads in which the coroutine dispatcher operates. In each thread management table 31-1, 31-2, ..., a request 18 having the same serialization identifier as that handled by the coroutine module currently operating in the thread is suspended for serialization. Have serialization target queues 32-1, 32-2 ,.

The coroutine scheduler 15 shown in FIG. 1 is called from each coroutine module like a subroutine and performs the processes (a) to (c) shown in FIG.

(A) Detect the coroutine id described in the call information request.

(B) The corresponding threat group management table is detected based on the coroutine id.

(C) Queuing the request in the request queue of the detected threat group management table, and returning to the calling coroutine module.

The coroutine dispatcher operates on each thread and performs the processes (a) to (p) shown in FIG.

(A) First, it is determined whether a request is connected to the thread in which the current coroutine dispatcher is operating,
The determination is made by checking the serialization target queue in the threat management table shown in FIG. If not connected,
Move to processing (e).

(B) If the requests are connected, take the request.

(C) Detect the coroutine module corresponding to the taken request.

(D) If the detected coroutine module is started and the coroutine module is restored, the process (a)
Return to and repeat the same process.

(E) When the request is not connected to the serialization target queue of the thread, the request queue of the thread group management table is checked, and one request is taken from the request queue corresponding to the thread.

(F) It is determined whether the thread is a thread that uses the serialization function. This is determined based on information statically set in advance in the thread management table or the thread group management table. When using the serialization function, move to processing (i).

(G) When the serialization function is not used, the coroutine module corresponding to the taken request is detected.

(H) If the detected coroutine module is started and the coroutine module is restored, the process (a)
Return to and repeat the same process.

(I) When using the serialization function, the serialization identifier set in the request is detected.

(J) Other threads in this thread group are compared with each other by checking other thread management tables linked to the thread management table.

(K) It is determined whether there is another thread to be compared. If not, move to process (n).

(L) If there is another thread to be compared, it is determined whether the thread is activating the coroutine module with the same identifier as the serialization identifier. If not started, the process returns to the process (j), and the other threads are checked in the same manner.

(M) If the threads are being activated with the same serialization identifier, the request is connected to the serialization target queue in the thread management table of the thread to be compared. After that, the process returns to the process (a), and the same process is repeated.

(N) If there is no thread operating with the same serialization identifier, record the serialization identifier of the request in the thread management table.

(O) The coroutine module corresponding to the taken request is detected by the coroutine identifier.

(P) If the detected coroutine module is started and the coroutine module is restored, processing (a)
Return to and repeat the same process.

The above coroutine dispatcher processing is the processing when the inter-coroutine serialization function is used. When the serialization function in the coroutine is used, the processing (1) to processing (m) shown in FIG. 6 are changed as shown in FIG. 7, for example. This will be described below with reference to FIG.

(L) It is the same as the process (l) in FIG. If "yes", the process (q) is executed.

(Q) With reference to the thread management table, this thread determines whether to use the in-coroutine serialization function. If not used, move to process (m).

(R) When the intra-coroutine serialization function is used, it is determined whether the coroutine module in operation and the requested coroutine module are the same. If the same, the process moves to the process (m) for serialization in the coroutine.

(S) If they are not the same coroutine module, record the serialization identifier of the request in the thread management table.

(T) The coroutine module corresponding to the taken request is detected by the coroutine identifier.

(U) When the detected coroutine module is started and returned from the coroutine module, the process returns to the process (a) shown in FIG. 6 and the same process is repeated.

(M) It is the same as the process (m) shown in FIG.

The above processing can be applied to a program for controlling the same request randomly when the same request comes in the online transaction processing, for example. By coroutine control, the control mechanism can be simplified and the execution multiplicity can be increased. You will be able to improve.

〔The invention's effect〕

As described above, according to the present invention, a simple control mechanism can be realized by controlling the activation of the coroutine module by the coroutine dispatcher on each execution body. In addition, since there is a part that does not need to use the lock mechanism provided by the OS, the execution body can be effectively used and the processing can be executed efficiently. This makes it possible to shorten the turnaround of the processing of the entire control mechanism.

[Brief description of drawings]

FIG. 1 is an explanatory view of the principle of the present invention, FIG. 2 is an explanatory view of an embodiment of the present invention, FIG. 3 is a time chart of the embodiment of the present invention, and FIG. 4 is a management table relationship used in the embodiment of the present invention. 5 and 5 are process flows of the coroutine scheduler according to the embodiment of the present invention, FIG. 6 is a process flow of the coroutine dispatcher according to the embodiment of the present invention, and FIG. 7 is a modification of the process flow of the coroutine dispatcher shown in FIG. Example, FIG. 8 shows an example of a general program execution control mechanism, FIG. 9 shows an example of calling a coroutine, FIG. 10 shows an example of conventional exclusive control, and FIG. 11 shows an example of conventional coroutine execution. In the figure, 10 is a processing unit, 11 is an operating system, 1
2-1 and 12-2 are execution bodies, 13-1 and 13-2 are coroutine dispatchers, 14A to 14D are coroutine modules, 15 is a coroutine scheduler, 16 is a request queue, 17 is a queue terminal, and 18 is a request.

Claims (1)

(57) [Claims] 1. A request (18) is passed between a plurality of coroutines, and a plurality of execution bodies (12-1, 12-2, ...) Are passed for each request.
In the data processing system in which the coroutine is multiplexed and operated as described above, for each request, the identifier of the coroutine that should process the request and the serialization identifier assigned to each unit that requires exclusive processing are set. , The processing means (14A, ..., 15) connected to the request queue (16) and the request connected to the request queue are fetched, and the same serialization identifier is used based on the serialization identifier set in the effect. Controls the serialization of coroutine activation by activating the coroutine if no coroutine is operating, or activates the coroutine if the coroutines having the same serialization identifier and the same coroutine identifier are not operating A plurality of coroutine dispatchers (13- 1, ...) and a coroutine call control method.