GB2357349A - Using multi-step processing in message processing - Google Patents

Using multi-step processing in message processing Download PDF

Info

Publication number
GB2357349A
GB2357349A GB9929996A GB9929996A GB2357349A GB 2357349 A GB2357349 A GB 2357349A GB 9929996 A GB9929996 A GB 9929996A GB 9929996 A GB9929996 A GB 9929996A GB 2357349 A GB2357349 A GB 2357349A
Authority
GB
United Kingdom
Prior art keywords
message
response
module
processed
processing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
GB9929996A
Other versions
GB2357349B (en
GB9929996D0 (en
Inventor
Kent Xu
Yu-Ning Zhang
Hung-Chang Tsai
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Inventec Corp
Original Assignee
Inventec Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Inventec Corp filed Critical Inventec Corp
Priority to GB9929996A priority Critical patent/GB2357349B/en
Publication of GB9929996D0 publication Critical patent/GB9929996D0/en
Publication of GB2357349A publication Critical patent/GB2357349A/en
Application granted granted Critical
Publication of GB2357349B publication Critical patent/GB2357349B/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/544Buffers; Shared memory; Pipes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/546Message passing systems or structures, e.g. queues

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)

Abstract

A response module identifier and a response flag are included in a message structure. When a sending module needs to transfer a message to a receiving module for processing, the response module identifier of the message is used to store the sending module's handle, and the response flag is set to indicate that the sending module is going to wait for the message to be completely processed by a receiving module. The operating system routes the message to the receiving module, where the receiving module determines if the message needs to be processed by multi-step processing. If so, it divides the message into a plurality of messages, the response module identifier of each storing the receiving module's handle. All these messages are caught and transferred to the receiving module for processing themselves, and the response flag is reset after the last such message is processed. Once processing is complete, the receiving module transfers a response message to the sending module using the response module identifier of the original message.

Description

2357349 METHOD OF USING MULTI-STEP PROCESSING IN MESSAGE PROCESSING The
present invention relates to a method of using multi-steps processing in message processing, and more specifically, to a message processing method of using response module identifiers and response flags.
In pass years, message-driven approach to be used very often in different operation systems of many communication products. Not only multi-steps processing is used most often, but also is one of the most important method in communication products. Call back functions, message definitions from individual procedures, and global parameters are some broadly used approaches conventionally. However, those methods' structures are messy and easy make mistakes. It is very disadvantageous for designing, software. For instance, when we set up a global parameter in computer programs, the parameter needs to be announced in the right places, how to maintain the announced global parameter still remains a problem for the designer. Therefore, there have some methods to be developed for overcoming the above problems, for example, SendMessage is an API (Application Prbgrammir% Interface) of Windows 95/98 for sending a message to an indicated process. However, double stacks need to be respectively set up for accessing data for message sending process and message receiving process. Not only, it wastes memory space, but also it would occupy much system resource if this message need to be processed for long time. This situation would affect the others tasks. In addition, a process that occupies almost all the system resources should be prevented in communication product. A multi- steps processing which usually manipulates the received message in a lot of processing steps.
Therefore, prior art that uses SendMessage API to deal with messages practically using, becomes much difficult. In order to eliminate the above mentioned disadvantages arisen from multi-steps processing, and to overcome the problems such as system being unstable, procedure being too large, complicated data structures and tremendous resources are required. Therefore, it is necessary to improve this method for using multi-steps processing of message driven system, not only those traditional defects above mentioned can be changed, but also decrease the developmental interval of products.
In accordance with the present invention, a method of providing a multistep processing of message-driven which includes a response module identifier and a response flag added in original message structure is disclosed. When a sending module needs to transfer a message to a receiving module for processing purpose, the response module identifier of the processed message is used to store the sending module's handle, then the response flag is set to indicate that the sending module is going to wait the processed being completely processed by the receiving module.
Next, the processed message is retrieved and then routed to the receiving module by operating system. When the receiving module receives the processed message, it firstly decides whether the processed message needs to multi-step processed or not. If multi-step processing is required, the receiving divide the processed into a plurality of 2 multi-step messages, wherein the response module identifier of each the multi-step message stores the receiving module's handle. All the multi-step messages are caught and then transferred to the receiving module for performing multi-step processing, and the response flag is reset after the last multi-step message is completely processed.
Then, the receiving module transfers a response message according to the processed message to the sending module by using the response module identifier of the processed message. Because only two members additionally included in the original message structure, it is quite convenient for the progranuners or designers to develop and maintain software on operating systems.
In the.drawings:
The foregoing aspects and many of the attendant advantages of this invention will become more readily appreciated as the same becomes better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein:
Figure 1 is a flQw diagram illustrating the steps of main program according to the present invention; Figure 2 is a flow diagram illustrative of the operation steps of the sending module according to the present invention; and Figure 3 is an operating flow diagram of the receiving module according to the present invention.
3 In traditional message driven approach, the method of multi-step processing is easy to cause defects such as structure messy, wrong value, unsteady large procedure or many stacks. This invention provides the method having clear structure and accuracy result, therefore a steady system composed of simple procedures and consuming few system resources are established. A response module identifier (e.g., named as m-AckModuleID) and a response flag (e.g., named as in-AcklockFlag) both are added in the original message structure, this make system structure clear and steady performance. Also, this method will reduce the system resource in whole system and cut down the product development cycle. This message structure consists of system main routines, sending message process flows and receiving message process flows.
The process flow of the message structure will be detail explanation as following.
Referring to Figure 1, a flow diagram illustrating the steps of main program according to the invention is shown therein. From the beginning of the procedure (step 10), the operating system checks the system message queue if there is any message (step 20). If it has not, repeatedly executes step 20; if it has, a message is retrieved from the system message queue (step 30). According to module handle,.for example m-Module in Windows 95/98 operating system in the original message structure, the system will pass the retrieved message to a related module indicated by the module handle (step 40). Step 40 can be either Figure 2, the processing flow of the sending module, or Figure 3, the processing flow of the receiving module. That means the flows of Figure 2 and Figure 3 are performed according to the value of the module identifier stored in the message structure of the retrieved message.
When the message has been completely processed, the response flag will be judged to be set up or not (detail explanation later) (step 50); if the response flag has 4 been set up, then goes back to step 20. If the response flag is not set up and the sending module which needs to response the retrieved message is effectively registered in operating system (step 60), the retrieved message must be the response message from the receiving module (step 70). According to the value of response module identifier in message structure, the response message is passed back to sending module and goes on multi-steps processing (step 80) such as Figure 3.
Figure 2 is a flow, which describes the processing steps of the sending module, wherein the system enters the flow chart from Fig=el step 40 to step 90. After the retrieved message is transferred (step 100), a decision step is performed to judge whether the retrieved message needs to be multi-step processed or not (step 110). If the retrieved message required to be processed by using multi-step processing, then the handle of the sending module will be stored in the response module identifier of the processed message that will be passed to the receiving module for processing'(step 120). After filling the message content required for the processed message (step 130), the processed message then transferred to the receiving module (step 140). The sending module then sets the response flag (step 150) and waits for response from the receiving module (step. 190). Then, the flow comes back to Figure 1 step 50 to judge the response flag whether it is set up or not. Since the response flag has been set up, it will come, back the procedure of between step 10 and step 40. Besides, if the response message (step 110) comes from the receiving module, related processes will be consecutively performed according to the response message (step 170) and finish the process of the sending module (step 190). Finally, Figure 1 will be finished and the system will come back to step 10. If the retrieved message does not need to be multi-step processed, associated processing are performed according to the retrieved message (step 180) and then returns to step 10 through step 190 Since the module handle (m_Module) of the message structure indicates the receiving module when the operating system gets the processed message from sending module (step 10-40), the system will execute Figure 3 which is the flow chart to describe the processes of receiving module. As noted, because the response flag is set in step 150 to indicate that the sending module starts to wait for response from the receiving module, whole the flow will return to step 50 in Figure 1 for continuing the consecutive steps. Since the response flag is set up at present, steps 20 and _'30 will be executed and then the system obtains the processed message from the sending module.
Next, related processing steps are performed by the operating system according to the module handle stored in the message structure (step 40). The receiving module will obtain the processed message from the sending module because the module handle indicates the receiving module has to process this processed message. When the receiving module starts to run and then decide whether the processed message neds to be processed by using multi-step approach or not (through steps 200 to 220).
The receiving module manipulates the processed message from the sending module at step 225 when the processed message does not need to be multistep processed. As noted, if the processed message must be manipulated by using the multi-step approach, some pre-processing steps before executing the multi- step approach are performed at step 225. Next, the receiving module decides whether the multi-step approach is required for the processed message at step 230. If the processed message does not need to be multi-step processed, the receiving module terminates the operation flow and releases the control rights to the operating system (step 340). If the processed message needs to be multi-step prooessed, then a "true" value to response flag will be set at step 240 and the multi-step messages derived from the processed message will be received by the receiving module because the response 6 module identifier of the multi-step messages stores the receiving module's handle right now (step 250). Then, the receiving module sets up the message type of processed message to be multi-step processed (step 260), and sends ihis message (step 270) to terminate the message process of the receiving module (step 340). It should be noticed, since the multi-step message is sent back to receiving module by the system,.
steps 200, 210, 220, 275-310, 290, 300, 510 will be repeated executed until the multi step processing is end. The above process is important from steps 240 to 250 because the multi-step message must be processed in the receiving module. In other words, after it executes from step 2 8 0 to step 3 10, the receiving module releases control rights back to the sending module to execute the step consecutive to the processed message.
The above message process will be explained detail as following.
If the processed message (step 220) needs to be multi-step processed, it is still going multi-step processing and checks whether the processing is finished (step '280).
If multi-step processing has finished already (step 275), then the response flag is clear for finishing the message process of the receiving module (step 320). Then, according to the module handle (m_Module) of the response module identifier, the response message of the processed message is sent back to the sending module and the flow will go back to Figure 1 step 50. Because the response flag has been cleared now, it will execute step 60. If the multi-step processing has not finished yet, the response module identifiers of the multi-step messages will store the handle of the receiving module to cause the receiving module to receive these messages (step 290) and again the message type is set to be multi-stJ processed (step 300). Then, the system sends these multi-step messages for finishing the message process of receiving module through step 3 10 to step 340. Of course, if the current message is not related to multi-step processing (step 220), the system executes the relatedaction according to 7 the current message (step 330) for finishing the message process of the receiving module (step 340).
Some advantages offer by the disclosed method. Firstly, both the sending and receiving modules are respectively activated by the received and processed message, system resources will not be occupied until the above-mentioned modules performs.
Secondly, only the response module identifier and the response flag required to be checked to obtain the current status under the multi-step processing. Furthermore, due to a simpler structure is disclosed, it is easier to maintain the system constructed by the disclosed method and the development cycle can be significantly degraded. Some broadly used data formats, for example BOOL (boolean), BYTE (byte), or INT (integer), can be employed in the invention according to the requirement of the applications.
In conclusion, the disclosed method performs associated functions in thesehding and receiving modules according to the module handle and accompanied with the additional response module identifier and response flag. The loading caused from system debugging and maintaining can be conveniently achieved because the simpler structure than the conventional is employed.
As is understood by a person skilled in the art, the foregoing preferred embodiments of the present invention are illustrated of the present invention rather than limiting of the present invention. It is intended to cover various modifications and similar arrangements included within the spirit and scope of the appended claims, the scope of which should be accorded the broadest interpretation so as to encompass all such modifications and similar structure.

Claims (10)

1. A method for performing multi-step processing in COmmunication devices, said method comprising the steps of.
transferring a processed message from a sending module, wherein a response flag of said processed message is set up and a response module identifier of said processed message stores a handle of said sending module; processing said processed message in a receiving module to generate a response message; transferring said response message to said sending module by using said module handle stored in said response module identifier, wherein said response flag is clear before transferring said response message; and processing said response message in said sending module.
2. The method according to claim 1, wherein both said response module identifier and said response flag are included in a message structure employed by said communication device.
3. The method according to claim 1, wherein said step of processing said processed message comprises the steps of.
sending multi-step messages from said receiving module, wherein said response module identifier of said multi-step messages store said handle of said receiving module; and receiving said multi-step messages by said receiving module for processing 9 said multi-steps messages.
4. The method according to claim 3, wherein said step of sending said multi-steps messages are repeatedly performed until said all multi-step messages being completely processed.
5. The method according to claim 1 fluther comprising a setting method performing before said step of transferring said processed message, wherein said setting method comprises the steps of.
storing said handle of said sending module in said response module identifier of said processed message; storing message contents of said processed message; setting said sending module for waiting said response message; and sending said processed message to said receiving module.
6. The method according to claim 1, further comprising a deciding method before performing said step of processing said processed message, said deciding method comprising the steps of.
deciding whether said processed message needs to be multi-step processed; and generating a plurality of multi-step messages according to said processed message when said processed message needs to be multi-step processed.
7. A method for performing multi-steps processing in communication devices, said method comprising the steps of..
transferring a processed message from a sending module, wherein a response flag of said processed message is set up and a response'module identifier of said processed message stores a handle of said sending module; generating multistep messages according to said processed message in a receiving module; sending said multi-step messages from said receiving module, wherein said response module identifier of said multi-step messages store a handle of said receiving module; receiving said multi-step messages by said receiving module for processing said multi-steps messages; generating a response message after all said multi-steps messages being processed; transferring a response message to said sending module by using said module handle stored in said response module identifier, wherein said response flag is clear before transferring said response message; and processing said response message in said sending module.
8. The method according to claim 7, wherein both said response module identifier and said response flag are included in a message structure employed by said communication device.
9. The method according to claim 7, further comprising a setting method performing before said step of transferring said processed message, wherein said setting method comprises the steps of.
storing said handle of said sending module in said response module identifier of said processed message; storing message contents of said processed message; sending said processed message; and setting said sending module for waiting said response message.
10. The method according to claim 7, flu-ther comprising a step of deciding whether said processed message needs to be multi-stepped processed performed before processing said processed message.
12
GB9929996A 1999-12-17 1999-12-17 Method of using multi-step processing in message processing Expired - Fee Related GB2357349B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
GB9929996A GB2357349B (en) 1999-12-17 1999-12-17 Method of using multi-step processing in message processing

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GB9929996A GB2357349B (en) 1999-12-17 1999-12-17 Method of using multi-step processing in message processing

Publications (3)

Publication Number Publication Date
GB9929996D0 GB9929996D0 (en) 2000-02-09
GB2357349A true GB2357349A (en) 2001-06-20
GB2357349B GB2357349B (en) 2002-06-12

Family

ID=10866610

Family Applications (1)

Application Number Title Priority Date Filing Date
GB9929996A Expired - Fee Related GB2357349B (en) 1999-12-17 1999-12-17 Method of using multi-step processing in message processing

Country Status (1)

Country Link
GB (1) GB2357349B (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112860453B (en) * 2020-12-14 2022-04-08 广州市玄武无线科技股份有限公司 Message management method, system, electronic device and storage medium

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0527590A2 (en) * 1991-08-08 1993-02-17 International Business Machines Corporation Distributed application execution
EP0564388A2 (en) * 1992-03-30 1993-10-06 International Business Machines Corporation Generalized control for starting of tasks (processes and threads)

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0527590A2 (en) * 1991-08-08 1993-02-17 International Business Machines Corporation Distributed application execution
EP0564388A2 (en) * 1992-03-30 1993-10-06 International Business Machines Corporation Generalized control for starting of tasks (processes and threads)

Also Published As

Publication number Publication date
GB2357349B (en) 2002-06-12
GB9929996D0 (en) 2000-02-09

Similar Documents

Publication Publication Date Title
US6948172B1 (en) Preemptive multi-tasking with cooperative groups of tasks
US4949254A (en) Method to manage concurrent execution of a distributed application program by a host computer and a large plurality of intelligent work stations on an SNA network
US5063500A (en) System for executing segments of application program concurrently/serially on different/same virtual machine
US5201049A (en) System for executing applications program concurrently/serially on different virtual machines
US5748959A (en) Method of conducting asynchronous distributed collective operations
EP0969383A2 (en) Method for efficient non-virtual main memory management
EP0644484A2 (en) Pre-emptive multi-tasking with co-operative groups of tasks
US5319782A (en) Method for synchronizing the dispatching of tasks among multitasking operating systems
KR970016979A (en) Queuing system and method of tasks in a multiprocessing system
US6738846B1 (en) Cooperative processing of tasks in a multi-threaded computing system
US5799314A (en) System and method of controlling mapping of data buffers for heterogenous programs in digital computer system
US5355488A (en) Method for adaptively building a library of program threads
CN115686805A (en) GPU resource sharing method and device, and GPU resource sharing scheduling method and device
JPH06231268A (en) Method and apparatus for storage and restoration of traversal-state attribute value of dag-structure network
JPH02300939A (en) Semaphore operation system
CN115964176B (en) Cloud computing cluster scheduling method, electronic equipment and storage medium
CN110851245A (en) Distributed asynchronous task scheduling method and electronic equipment
GB2357349A (en) Using multi-step processing in message processing
CN112346835B (en) Scheduling processing method and system based on coroutine
EP1374043A2 (en) Self-downloading network client
CN109983435A (en) Graphic processing method and relevant apparatus and equipment
CN115686802B (en) Cloud computing cluster scheduling system
EP0967549A2 (en) Processing asynchronously called operations of objects
JP2004234643A (en) Process scheduling device, process scheduling method, program for process scheduling, and storage medium recorded with program for process scheduling
KrOvChuck Virtual supercomputing on Macintosh desktop computers

Legal Events

Date Code Title Description
PCNP Patent ceased through non-payment of renewal fee

Effective date: 20181217