JPS5970340A - Communication processing control system - Google Patents

Abstract

PURPOSE:To attain the communication processing control with good performance, by realizeing the communication processing request required for simultaneous parallel processing as a continuous processing, by using a virtual wait function. CONSTITUTION:The system consists of a requesting module RM, a communication process executing module EM, and a basic control module BM, and the EM comprises a communication processing section EMA and a communication control section EMB. A preprocessing PROLOG receives a communication processing request HCREQ from the RM, ensures a working memory WA of the EM to this request and saves a register of the RM. A post processing EPILOG recovers a register of a calling party and releases the working memory WA. A virtual wait function section X showns the reality of the virtual wait instruction realizing the virtual function issued by the EM, and a continuity processing control section Y guarantees the continuity processing of the EM interrupted at the point of time of the virtual wait instruction based on the notice from the BM.

Description

DETAILED DESCRIPTION OF THE INVENTION Object of the Invention The present invention relates to a control method for a data communication processing system, which is one node of a data communication network and is composed of multilayer modules suitable for program execution.

BACKGROUND OF THE INVENTION A control system for a data communication processing system on a data communication network as shown in FIG. 1, which is comprised of such multilayered modules, will be described below. In the figure, NASNB is a node (for example, a computer) in a data communication network, NW is a communication network, and RM
is the request source module, EM is the communication processing execution module,
BM is a basic communication control module. Both nodes NA,
The NBs are connected via a communication network NW. The requesting module RM on the node NA issues a communication processing request to the communication processing execution module EM, such as virtual terminal access and file transfer to the other node NB. The communication processing execution module EM receives the communication processing request from the higher level, uses the functions provided by the lower level basic communication control module BM multiple times as necessary to complete the process, and requests the results. The original module RM is notified. The communication processing execution module EM, like the basic communication control module BM, performs such processing simultaneously on a large number of paths in parallel. The interface between the communication processing execution module EM and the basic communication control module BM also takes the form of communication requests and result notifications.

Conventionally, in communication processing modules such as the above-mentioned communication processing execution module and basic communication control module, a request from a higher level and a result notification from a lower level (hardware or software) are generally called triggers, and communication processing The module is activated every time these triggers are received, makes requests to the lower level, accumulates transmission blocks, etc., and records the current state, that is, the status (for example, after sending a polling sequence), in order to continue processing at the next trigger reception on this path. Message reception wait status) is set in the control table for this path, and processing for this trigger ends. When a result notification is received from a lower level, the communication processing module is activated again, and based on this trigger and the path status, the communication processing module executes the continuation process, and if a request to a lower level is necessary, it requests again, and updates the status (e.g. , BTB (End o
f Tra'n5m1ssionBlock ) Next block reception wait status after block reception, etc.) is set in the control table of this path, and the processing for this trigger is ended. A control method in which processes are executed sequentially based on status and triggers in this manner is called a status/trigger method. Generally, in this method, the operation of a module is described using a state transition diagram as shown in FIG. 2 or a state transition table as shown in FIG. In Figure 2, ASB, C, D, and E in the circle mark 4 indicate status, A, I, TS, WORK, O, and force indicate triggers, and arrows indicate state transitions. For example, when a trigger "tsu" is received in status C, it indicates that the status changes to status D. In Figure 3, English letters and katakana indicate status and trigger, respectively, and each intersection, for example, the intersection of status C and trigger "tsu""processing 4 → D"
indicates that when a trigger "tsu" is received in status C, process 4 is executed and the status changes to status D. In general, state transition tables have better expressive power in that they can describe not only state transitions, but also processes, as described above, and are often used for specification descriptions.

Now, in the status trigger method, the logic is broken at each intersection of the state transition table shown in Figure 3, and the generation of handover information for continuous processing execution for the next trigger, setting of this handover information in the control table corresponding to the path, and so on. This method has drawbacks such as increased overhead due to the distribution of processing based on status and triggers.

OBJECTS OF THE INVENTION An object of the present invention is to improve the drawbacks of the status trigger method described above in communication processing control that uses basic communication control modules to perform more advanced communication processing, and to continuously operate modules. The objective is to provide a communication processing control method that can be realized as a logical logic, reduce overhead, and have good performance.

The present invention provides continuous logic for each function provided by the communication processing execution module to the request source module. Waiting for completion is virtually realized using the virtual wait function, which eliminates the need to set takeover information such as status for continued processing when accepting the next trigger.This virtual wait function can be used in general operating systems. Unlike the WAIT function (which puts tasks in a waiting state to synchronize events), which is one of the task control ,
Do not put the running task in a waiting state (the execution of the request source module is stopped while waiting for the request to complete).

Furthermore, the address of the working memory of the communication processing execution module is set in the fixed area of the control memory used when making a communication request to the basic communication control module and when notifying the result, and all registers at that time are set during virtual wait. The communication processing execution module is saved in a part of this working memory.
(Freezes the execution state of the caller as it is) and returns control to the caller. After that, the address of the above-mentioned working memory is obtained from the control memory that is returned when the communication request result is notified, and all the registers at the time of the virtual wait are recovered, and the return is made to the time of the virtual wait (the communication processing execution module is released from the frozen state) ), it is possible to continue processing, and distribution using the status trigger method reduces processing overhead. Further, unlike the task e-dispatcher in a general operating system, it does not perform complicated processing such as selecting a task to be started from among a large number of task groups. Note that the working memory of the communication processing execution module is reserved for processing the communication processing request in the communication processing execution module when receiving the communication processing request from the request source module.

Examples of the invention Embodiments will be described in detail below according to embodiments shown in the drawings.

FIG. 4 is a schematic diagram showing an embodiment of the present invention. In the figure, boxes M, EM, and BM correspond to the requesting module RM, the communication processing execution module EM, and the basic communication control module BM in FIG. 1, respectively. The communication processing execution module BM includes a communication processing unit EMA and a communication control unit EMB.
It consists of PROLOG and EPILOG are pre-processing and post-processing, respectively, of the communication processing section. In the preprocessing, when a communication processing request is received from the requesting module RM, the processing memory WA of the communication processing execution module EM is reserved for the request, and the register of the requesting module M is saved. Post-processing includes restoring the caller register and releasing the working memory WA. (X is a virtual way that realizes a virtual wait function issued by the communication processing execution module) (VWAIT) A virtual wait function unit that is the substance of the command, Y is a virtual way that realizes the virtual wait function issued by the communication processing execution module, and Y is the virtual way that realizes the virtual wait function issued by the communication processing execution module. This is a continuation processing control unit that guarantees the continuation of the interrupted communication processing execution module EM.

Now, the actual control operation will be explained with reference to FIG. In the following explanation, from the requesting module fLM to the communication processing execution module EM1 and the communication processing execution module ILP.
, the request format from M to basic communication control module BM is S.
A vC call (supervisor call) is assumed, and the notification format from the basic communication control module BM to the communication processing execution module EM is also an SVC call. That is, both the communication processing execution module EM and the basic communication control module BM are SVC routines. In FIG. 4, ■, 8, ■, ■, etc. indicate the order of processing. Further, although the arrows in FIG. 4 indicate control transfer, the return of the SVC call is not clearly indicated. The communication processing requests HCR and EQ from the request source modules R and M are sent to the communication processing execution module E.
When M accepts (■), PR and 0LOG secure working memory WA of communication processing execution module BM, and caller R
The M register group is saved to WA (■), and communication processing is started. This is done by issuing a communication request BCREQ to the basic communication control module BM. The basic communication 1 control module BM receives the communication request BCREQ, executes processing therefor, and issues an input/output request (0). The control memory (control block CB) handed over to the basic communication control module BM at the time of communication requests BCR and EQ is used to transfer various information (for example, the storage area address of input messages) between both modules at the time of request and notification of results. but,
A storage information area is provided in this control block CB in which the information at the time of the request is stored as is and is delivered together with the result notification when the request processing is completed. The communication processing execution module EM sets the address of the above-mentioned working memory WA in this storage information area at the time of communication request BCR, EQ (■). Then BC1 (
, a virtual wait instruction (VWAIT) waits for the completion of EQ.
) is issued (■). The substance of this instruction (inline macro instruction) is the virtual wait function section X, and its processing contents are as shown in the flowchart in FIG. All current registers of 4 are saved to the processing execution module E in the VWAI'l' register in the working memory WA.
AV (as a result, the communication processing execution module E
(The execution state of M is frozen and saved at VWAI'I' due to processing), the caller (RM in this case) register group of the communication processing execution module EM is recovered and the process returns to the caller. This state is a virtual wait, and in terms of control, the processing of the communication processing execution module BM is completed and returns to the caller, but the processing is interrupted at VWAIT and the communication to the basic communication control module BM is terminated. The request BC1 (is in a state of waiting for the completion of EQ. The caller that returns with the first V'WAIT in the communication processing execution module HM is the requesting module RR4, and the communication processing execution module EM is waiting for the request to be completed. When returning a return code etc. to the original module RM, it is necessary to set it in a register etc. before issuing VWAIT.

The basic communication processing module BM executes processing for the communication request BCREQ (■), and after completion (■), notifies the communication processing execution module EM (■). This notification format is here the KSVC call (i.e., the continuation process control unit Y&''!, SvC routine) as described above. This SVC routine is the continuation process control unit Y in FIG. 4. This continuation process control The unit Y is activated by the basic communication control module B+V as an SVC call as a notification of completion of the communication request BCREQ.As shown in FIG. The group is saved to the working memory WA, and the communication processing execution module E is saved from the saved information area in the control block CB at the time of the request to be taken over.
Get the address of M's working memory WA and write V in WA'.
All the registers at VWAIT are recovered from the WAIT register save area WAV, and the VWAI in the communication processing execution module EM is restored using the return address indicated by register BR.
Transfer control to next T (■).

As a result, the communication processing execution module EM
The saved state at time T is canceled as is. Thereafter, the communication processing execution module EM is the SVC of the continuation processing control unit Y.
It operates as an extension of the call, and if the request from the requesting module RM is not completed (for example, all transmission blocks have not been read in a message read) (■, ■), the communication request is made again and the VWAIT Issue. In this VWAIT, the SVC call source is the basic communication control module BM, so the virtual wait function unit
Return to basic communication control module BM. After that, the above steps are repeated until the processing from the request source module RM is completed. When the process is completed, after notifying the request source module RM (@), the SVC caller at that point (
If the basic communication control module BM is running as an extension of the SVC call of the result notification, the basic communication control module BM
, if the first communication request BCREQ is rejected due to an error or other reason, and is running as an extension of the SVC call for a communication processing request from the requesting module RM, the register group of the requesting module RM) recovery, working memory W
Releases A and returns to the caller (@).

In the embodiment described above, the communication processing execution module EM, which has received a communication processing request from the requesting module M, performs communication processing for each communication processing request so that parallel processing can be performed. A working memory is secured for use within the processing execution module EM, and this working memory is subsequently used until the series of processing of this communication request is completed. The impossible I/O request wait is virtually realized, and the setting of status and other takeover information using the conventional status trigger method is no longer necessary. Furthermore, by setting the above-mentioned working memory address (in which all registers are saved during virtual wait) in the control block CB of the request to the basic communication control module BM and passing it around, the conventional status and trigger can be set when the result is notified. (The processing request to be processed is determined by rotating the control block CB, and the processing continuation address is determined from the specific register BR saved in the working memory.) These improvements will improve the performance of communication processing control, and will also make it possible to improve the efficiency of communication processing module development, design, manufacturing, testing, etc.

In the embodiment described above, the notification format from the basic communication control module BM to the communication processing execution module EM is an SVC call, but this does not necessarily have to be the case. For example, if this is not the case on a typical operating system.
Even if the continuation processing control unit Y is an independent task in the form of GiveAndPa5t (GiveAndPa5t: notifying the occurrence of an event and requesting processing from another task), the continuation processing control unit Y uses exactly the same method as in the embodiment. This allows continuous control of the communication processing execution module EM. In this case, the return to the caller in the virtual wait function unit It is necessary to create the virtual wait function section X so that it becomes an unconditional branch to the above-mentioned continuation processing control section Y, rather than a return to the 8VC call.

Similarly, in EPILOG, it is necessary to include processing of an unconditional branch to the continuation processing control unit Y. Furthermore, in the embodiment, the working memory of the communication processing execution module EM is secured and released by PR, 0LOG (preprocessing), and EPILOG (postprocessing) in the communication processing execution module EM, but this is not necessarily the case. It doesn't have to be the street. Requesting modules R and M hand over the working memory secured by the requesting module at the time of a communication processing request, eliminating the need to secure and release it within the communication processing execution module EM, and requesting module RM reclaims this working memory. By using it, performance can be further improved.

Effects of the Invention As explained in detail above, according to the present invention, communication processing requests that require simultaneous parallel processing are processed continuously using a virtual wait function, instead of being processed as a collection of small-scale processing by Religer. This eliminates the need for setting transfer information such as status, sorting based on status and triggers, and has the effect of easily realizing and controlling communication processing with good performance.

[Brief explanation of drawings]

FIG. 1 is a block diagram showing an example of a system to which the communication processing control method of the present invention is applied, FIGS. This figure shows an embodiment of the present invention, and FIGS. 5 and 6 are flowcharts of a virtual wait function section and a continuation processing control section, respectively, which are the main functions of the control system of the present invention. , 6 NA, NB... Nodes on the data communication network, NW...
Communication network, RM...Request source module, EM...Communication processing execution module, BM...Basic communication control module, DMA...Communication processing unit, EMB...Communication processing control unit, X. ...Virtual wait function unit, Y...Continuation processing control unit, PROLOG...Pre-processing, EPILOG...Post-processing, Hen, EQ...Communication processing request to communication processing execution module, BCREQ... ...Communication request to the basic communication control module, VWAIT...Virtual wait request, WA...Working memory used by the communication processing execution module, CB...Control memory (control block). Representative Patent Attorney Susuki 1) Rinoks 1'5 Figure 1'6 Figure

Claims (1)

[Claims] A data communication processing system that is one node of a data communication network and consists of a request source module that issues communication processing requests, and a communication processing execution module that processes this request using a lower-level basic communication control module. , when the communication processing execution module that has received the communication processing request from the requesting module issues a communication request to the lower-level basic communication control module, the communication processing execution module's work is assigned for each communication processing request from the requesting module. After passing the address of the working memory, all registers are saved to this memory, the result of the communication request to the lower module is virtually waited, and the working memory and registers being executed are frozen as they are. returns to the requesting module, recovers all registers at the time of virtual wait upon notification of the request result from the lower module, releases the virtual wait state, restarts module execution from the frozen point, and then continues processing. It is characterized by repeatedly executing control transfer based on communication requests, virtual weights, and release with lower modules according to the request, and notifying the requesting module of the result after the final processing is completed. Communication processing control method.