KR930007981B1 - Mail box communication method - Google Patents

Abstract

The data is formatted to a special form and transmitted to target task using subroutine provided by multi-task operating system. The method comprises the steps of: (A) writing execution request data on a local memory area of a second task and calling operating system utility; (B) copying content of operating system and storing on area supervised by an operating system; (C) checking data input to a second task by calling a subroutine when a second task receives priority; (D) copying corresponding data of operating system to a local area occupied by a second task; and (E) analyzing the data and executing according to the data.

Description

Mailbox communication method in multi-task operating system environment

1 is a flow diagram of a conventional inter-task information transfer.

2 is a block diagram of the present invention.

3 is a system structural diagram according to a program structure.

4 is a diagram illustrating an entire format of a mailbox.

5 is an operation flowchart of an embodiment of the present invention.

6 is a flowchart when the OS receives an information transfer request.

7 is a flowchart when the OS receives confirmation of presence information.

The present invention relates to a method of communication between tasks in a multitask operating system (hereinafter referred to as an OS) in a facsimile system. Particularly, in the case of transferring information from one task to another task, The present invention relates to a communication method between tasks in which information delivered to a memory area is recorded in a predetermined format, and then subroutines provided by a multitask OS are used to transfer information at an OS level.

Until now, the concept of inter-task communication did not have to be applied to facsimile systems.

However, as the functions of the facsimile system were gradually diversified, the facsimile system configuration program was modularized to execute the program of tasks. As a result, the necessity of multitasking and communication between tasks became recognized. A task is a program routine for performing a certain purpose.

In the facsimile system to date, a simple kind of intertask transfer of information has been performed, but this is not provided by the OS, but by inter-task protocol.

For example, in a program consisting of A, B, and C tasks, the A task and the B task have performed a method of writing and reading each other using a predetermined memory area, and the A task and the C task use another memory area. Assume that the task is performed by determining and transferring information between tasks.

For example, as shown in FIG. 1, when task A is started, the memory area is checked to determine whether there is information transfer from tasks B and C that need to communicate with task A, and if the information is If so, the routine is processed. However, the conventional method described above requires comparison information of routines for checking whether there is a large amount of memory area and transfer information between tasks when transferring information between one task and several tasks. There was a problem with no communication diversity. Accordingly, an object of the present invention is to record information to be delivered to a memory area of a task in a predetermined format when calling from one task to another, and then calling a subroutine provided by a multitask OS. The present invention provides an inter-task communication method for delivering information at an OS level.

Hereinafter, the present invention will be described with reference to the accompanying drawings.

2 is a block diagram of the present invention. The CPU 100 collectively controls the overall operation of the system, a ROM 200 which is a program area in which a plurality of tasks are to be performed, and a local memory area of each task. 302 and a RAM 300 composed of an OS jurisdiction memory region 301 which is controlled by the OS. However, the number of tasks may be expanded in consideration of the capacity of the ROM 200 and the RAM 300.

3 is a system structure diagram according to the program structure of the present invention, each task can always transmit its information to the counterpart task using the OS to request any operation of the counterpart task, and to transfer information between tasks and any requests. In this case, it has a configuration in which communication between tasks is performed by recording in a local area of each task in the same format as that of the fourth figure described later and calling a utility of the OS.

4 is a diagram illustrating an entire mailbox format according to the present invention. 401 is the number of words from 405 to 409 (in the case of one word of two bytes), and the OS utility transfers information with reference to this length.

402 is a task ID for receiving corresponding information.

403 is a task ID for transmitting the corresponding information.

404 is a dummy part for expanding information.

405 to 407 serve as the discriminating means when the user needs to distinguish the mailboxes.

408 is the body length of the mailbox (409 part lengths of information required for each task).

409 is an area for creating information to be delivered for each task.

5 is a flowchart illustrating an operation of an embodiment of the present invention, FIG. 6 is a non-inventive flowchart illustrating a case where an information transmission request is received, and FIG. 7 is a flowchart of the present invention illustrating a case where an OS receives confirmation of reception information. to be.

The present invention will be described in detail based on the above configuration.

There are several tasks in the system environment, such as the second degree where the OS is provided, and each task can use the same tasks A, B, C, and C as the third degree in the case where the license of the CPU 100 can be obtained from the OS at any time. D needs each other to transmit necessary information and perform tasks. For example, a detailed operation procedure for the case of transmitting information from task A to task B will be described with reference to FIG. 5.

The OS grants the right to task A (T1). As a result, when task A is performed (T2), and any task request is made to task B, there are several methods of delivering this task request. The task A records the performance request to the task B in its local area in accordance with the format of FIG. 4 (T3). Thereafter, when the OS utility is called (T4), the OS copies and stores the contents in the area controlled by the OS (T5). When task B receives the execution right from the OS (T6), when the OS utility is called (T8), which information is transmitted from another task (T8), the OS copies the contents to the local area of task B. (T3). The task B analyzes the contents by referring to the format of FIG. 4 (T10) and performs the task B (T7). At this time, the task ID 402 for receiving the information becomes B, the task ID 402 for transmitting the information becomes B, the task ID 403 for transmitting the information becomes A, and the task A When task B acknowledges the information from the local area, the information is copied by the number of words 401 to 405-409. Herein, referring to FIG. 6, the operation procedure of the case where the OS receives the information transfer request (T4), first checks the task ID of the information transfer request source, and then checks the corresponding information receiving task ID. The inter-task information storage area of the OS jurisdiction is determined with reference to the request source task ID and the received task ID.

If it is determined that the determined area is available and the delivery information still remains, the information delivery request task is notified of the information delivery impossibility and terminates. On the other hand, if it is determined that the determined area is available, the transmission information is copied to the corresponding area, and the information delivery request source is notified of the completion of the information delivery and ends.

On the other hand, when calling the information transfer request OS utility as described above, the response from the variables required for the OS to perform it and the accompanying information transfer request OS utility is the address of the local area and the information transfer completed in FIG. Or not. Next, referring to FIG. 7, the specific operation procedure at the time of request for confirmation of reception information (T8) will be described. First, the task ID for confirming the reception of information is examined, and then the task ID for the reception request is examined and information is transmitted from the task. Check it.

If it is determined that there is no information transmission as a result of the confirmation, it notifies the information receiving confirmation task that there is no information to receive and ends. On the other hand, if it is judged that there is information transmission from the receiving request task, the transmission information is copied to the local area of the receiving task, and then informs the acknowledgment request task that there is information to receive and ends.

On the other hand, when calling the reception information confirmation OS utility as described above, the response required from the OS and the accompanying reception information existence confirmation OS utility to perform this operation is 'receive request task ID and reception information', respectively. Address of local area to receive and 'receive information present or not exist' message.

Confirmation of information transfer request OS utility and reception information such as the above-mentioned buffer OS utilities are applied to the OS of the system in which multiple tasks are operated to facilitate communication between tasks, and at the same time, the information transfer task calls the OS utility to receive information. There is an advantage that it does not have to wait for the delivery information to be received. That is, after task A calls the OS utility and checks the response terminal, reception of the delivery information is performed when task B has received the execution right from the OS. As a result, system efficiency is improved in a system environment in which multiple tasks are operated.

In addition, even if the transfer information between tasks is large, there is an advantage that the range of performance of the task can be widened by the communication between tasks.

Claims (3)

In a method of communication between tasks of a multitask operating system having a jurisdiction local area for each task and having an operating system and a common area jurisdiction of the operating system, any first task that is being performed may request execution of a second task. 2 Task A first step of recording the execution request to the second task in its own local area in a predetermined format and invoking the operating system utility, and copying and storing the contents of the operating system in the area jurisdiction in the operating system. And a third step of invoking an operating system utility to determine what information was transmitted from another task when the second task received a right of execution from the operating system, and the corresponding information in the operating system. 2 Task's furnace A fourth process of copying the area and, in the communication method for the second task, characterized by a fifth constituted by any process running to analyze the information from the format. The method of claim 1, further comprising: a first step of invoking the information transfer request operating system utility, a first step of checking a task ID of the information transfer request source and then confirming the corresponding information receiving task ID, and a task of the operating system jurisdiction; A second step of determining the information storage area with reference to the requester task ID and the receiving task ID and checking whether the determined area is available; copying the delivery information to the corresponding area if the information is available in the determined inter-task information storage area; And a third step of notifying the completion of the delivery and, if not available, notifying the information delivery requester task of the inability to deliver the information. 3. The method of claim 2, wherein the third step of invoking the reception information existence operating system utility comprises: a first step of checking a task ID for confirming information reception; and a second step of checking presence of information from a reception request task; And, if there is information transmission from the receiving request task, copy the delivery information to the receiving area's local area and notify the acknowledgment request task that there is information to receive, and if there is no information to receive, send it to the information receiving confirmation task. And a third step of notifying.