CA2349706C - Method and apparatus for evaluating a data processing request performed by distributed processes - Google Patents
Method and apparatus for evaluating a data processing request performed by distributed processes Download PDFInfo
- Publication number
- CA2349706C CA2349706C CA002349706A CA2349706A CA2349706C CA 2349706 C CA2349706 C CA 2349706C CA 002349706 A CA002349706 A CA 002349706A CA 2349706 A CA2349706 A CA 2349706A CA 2349706 C CA2349706 C CA 2349706C
- Authority
- CA
- Canada
- Prior art keywords
- data processing
- supporting
- processes
- message
- indicators
- 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.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/45—Exploiting coarse grain parallelism in compilation, i.e. parallelism between groups of instructions
- G06F8/458—Synchronisation, e.g. post-wait, barriers, locks
Abstract
A database processing request is performed by distributed processes. Each of the distributed processes involved in the task performs some data processing function and includes process identifying information along with a substantive task messa ge to another process. Ultimately, messages along with the identifying information reach a controlling process which then deduces from that identifying information whether all of the messages from all processes involved in the task have completed their part of the tas k. If it deduces they have, the task is complete.
Description
METHOD AND APPARATUS FOR EVALUATING A DATA PROCESSING
RF Qi 1F STPLRF tvrFn BY DI5JBMJITED PR F SSLS
FTF.I.D OF IM EMNTION
The present invention relates to perfornling tasks using distributed processes either in the context of a singlo data processor or in a multiprocessor context.
While the present invention finds advantageous application to any cooperative effort to perform a task, one example application is to database query evaluation in data rnanagement systems.
BACKGROUND AND SUMMARY OF THE INVENTION
In database managamcnt, data is organized and stored in electronically readable form for subsequent shared access by multiple computer users.
Database engines enable those users to submit queries addressing such data, which may be organized conceptually in relational, tabular, hierarchical or other forms, and to receive in response to a query an output known as an answer set. The following is an example is of a query. Assume there is a register of employees in a particular company. For e.aeh employee, there is stored (among other things) the employee's name, salary, and age.
One possible query is to "find all names of employees that have a salary of more than $20,000 and are less than 30 years old."
Under various circumstances, answer 9ets can take a significant amount of zo time to produce, and this problem rnay be significant. Therefore, database management systems often employ multiple processes operating on a single computer or multiple processors to perform a query by breaking each query request into interrelated tasks that can be executed by using multiple processes or processors. In otlier words, each process or processor performs some part of the execution of the query.
25 Multiprocesslprocessor systems, in general, are known. For example, U.S.
Patent No. 5,668,714 to Morikawa (assioned to Fujitsu) describes a multiprocessor apparatus baving plural processors in which each processor is assigned to a partic-ular process.
Unnecessary or excess processors are released from their assignment to a process, and if the number of processes assigned to the process is insufficient, one or more idle AMENDED SHEET
~
processors is assigned to the process. The query results produced from all of the cooperating query processes (i.e., query operators) are gathered and combined to generate the required query response/answer set. -The difficulty in a distributed query execution specifically, and in any s type of distributed processing system generally, is knowing when all of the intcrconnectcd and cooperating processes have completed processing of their respective portions of the overall task. Consider the example distributed processing scenario shown in Fig. 1. A user terminal 10 communicates with a computer system 12 by way of a user iAterface 14. In the context of a database management systan, the computer i o system 12 may also be connected to a database 16. A task (such as a database query) from the user interface 14 is provided for distributed execution to a controlling process C which then passes the task (or portions tbereot) to supporting processes P1, P2, P3, and P4 as shown. Each process P1-P4 executes some part (or its own portion) of the task. More specibcally, controlling process C sends a measage defining or 15 otherwise related to the task to the first process P1. rirstprocess P1 performs its part of the task and sends those partial task results along with the message it received from the controlling pxocess C both to supporting processes P2 and P3. The supporting processes P2 and P3 perform their respective parts of the task and send their respective results along with the message each received from the process P1, which includes the 20 results from the process P1, to supporting processes.
The completed task reaches the controlling process C in the form of two messages, one from the chain C--),P1-3P2--~C and one from the chain C-4P 1-aP3--->P4-3C. The problem at this point is for the controlling process C to determine when it has received all messages from all of the agent processes involved in 25 performing the task. This problem is complicated by the fact that while the contrailing process knows about the first supporting process Pi, it does not necessarily know the identity of all supporting processes that contributed to the completion of the task. As a result, the controlling process C does not even know how many process messages to expect.
AMENDED SHEET
One possible solution to this problem is for all of the supporting processes P to inform the controlling process C of their identities and then to send a message from the controlling process C to each of the supporting processes P(i.e., Pl - P4 in Fig. 1) requesting that each of the supporting processes communicate with the controlling process C when they have completed its portion of the task.
Each supporting process P then sends another message to the controlling process C
when it has completed its respective task portion. One drawback of this solution is that it requires that the identity of all the supporting processes that will be involved in executing some portion of the task be known in advance by C. This requirement is not io always easy or desirable to meet. Another significant drawback of this possible solution is that all of the overhead-type signaling between the controlling process C
and the supporting processes is time consuming and inefficient.
It is an object of the present invention to provide efficient distributed processing of a task in a timely fashion.
It is an object of the present invention to perform distributed processing of a task using plural processes without the need for overhead signaling between various processes.
It is an object of the present invention for a controlling process in a distributed processing environment to be able to deterniine from the messages received 2o from distributed processes executing a portion of the task when the task is complete without having specialized signaling between the controlling process and each supporting process.
It is a further object of the present invention to provide an efficient distributed processing technique where the controlling process does not even need to ^s know the number or the identities of supporting processes which will participate in the distributed execution of a task.
The present invention solves these problems and satisfies these and other objects. Rather than sending control messages back and forth between the controlling process and each supporting process, each process includes some type of identifying information that it forwards to a supporting process along with a substantive task =
message. Ultimately, those messages with the identifying information reach the controlling process. The controlling process then deduces from the received identifying information whether all of the messages from all processes involved in the task have been received. If the controlling process deduces they have, the task is complete.
In one example embodiment, as a message related to a data processing io task is passed between those processes involved in performing the data processing task.
Each of those processes performs some function related to the task and passes an "end token" along with the message -- as modified by the function performed by that process -- to another of the involved processes. The control process determines that the data processinD task is finished using the end tokens received along with the distributed processing results from the involved processes. Each end token includes a unique identifier and the number of copies of the message forwarded by the corresponding process and is used by the control process to generate an arrav of count values. A count value is established for each unique end token based on the number of inessage copies forwarded by the corresponding process. When all of the count values are decremented to zero, the controlling process determines that the messages from all involved processes have arrived and processing is complete.
The invention has advantageous application to database management, and in particular, to database query evaluation. However, the present invention is not limited to database management or query evaluation and may be employed advantageously in any application where processes cooperate to achieve an overall goal.
The processes may be implemented in the same computer or at separate computers. In a single computer case, the processes may communicate for example using the message passing functionality of the computer's operating system. In a multi-computer case, each computer may communicate over an appropriate transmission medium such as a = shared memory, a local area network, the Internet, etc.
BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing and other objects, features, and advantages of the invention 5 will be apparent from the following description of preferred example embodiments as illustrated in the accompanying drawings in which-reference characters refer to the same parts throughout the various views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.
Fig. 1 is a diagram of a distributed process used to execute a data io processing task;
Fig. 2 shows a multi-processor, network-based distributed data processing system that may be used to execute a data processing task;
Fig. 3 is another configuration of a multi-processor data processing system that may be used to execute a data processing task where the processors are connected by a data bus and communicate using a shared memory;
Fig. 4 is a flowchart diagram illustrating procedures for evaluating the execution of a data processing request in accordance with an example embodiment of the present invention;
Figs. 5A-5C are flowchart diagrams illustrating various procedures for implementing the present invention in another specific, example embodiment of the present invention; and Figs. 6-8 illustrate example operations of the present invention -implemented using the specific example embodiment of Figs. 5A-5C in increasingly more complex distributed processing situations.
DETAILED DESCRIPTION OF THE INVENTION
In the following description, for purposes of explanation and not Iimitation, specific details are set forth, such as particular embodiments, process flows, and techniques, in order to provide a thorough understanding of the present invention.
However, it will be apparent to one skilled in the art that the present invention may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known methods, systems, and devices are omitted so as not to obscure the description of the present invention with unnecessary detail.
The present invention may be implemented in a variety of contexts. For example, the present invention may be implemented in a single computer based system such as that shown in Fig. 1 where distributed software processes are employed to cooperatively execute a task. Those processes communicate using the computer's operating software. In addition, the present invention may be applied to a multi-processor environment. One example multi-processor environment is shown in Fig. 2 where multiple nodes (1-4) identified with reference numerals 20, 22, 24, and 26 are connected by way of a network 30 such as Ethernet, Internet, etc. Each of the nodes 1-4 includes a data processor that performs some portion of the requested data processing task. The node data processors communicate using an appropriate communications protocol over the network 30. Fig. 3 shows another example multi-processor configuration where CPUs 1, 2, ... N corresponding to reference numerals 32, 34, and 36, respectively, are coupled to a shared memory 40 over a data bus 38.
However, these example applications are in no way limiting since the present invention may be used in any situation where there is a set of "things" sending messages, packets, etc. to each other in directed, acyclic manner.
Filz. 4 outlines example steps ior determining wiiether a data processing request has been completed by distributed processes as set forth in the Request Evaluation procedures (block 50). For ease of description only and in no way limiting, the present invention is described in terms of "processes" which may be implemented using one or more computers or other types of electronic data processing circuitry.
Initially, a task is assigned to a control process (C) for distributed or otherwise cooperative processing by a plurality of processes (block 52).
A message related to the task to be accomplished is sent from control process C to one or more supporting processes P w,hich assist in accomplishing the requested data processing task (block 54). Each supporting process P receives its own copy of the message from C and performs some proccssing function associated with the io message. After processing, each supporting processor forwards the received message along with the results of its processing to another supporting process. While in this example the message passed between processes is the same, different messages may also be passed between processes.
A supporting process P includes some type of identifying information, (e.g., a token as explained hereafter), with the message along with the results of the data processing performed (related to the assigned task) by that process (block 56). The control process C uses that identifying information collected from messages received from supporting processes to determine whether all processes performed by all of the supporting processes P involved in executing the assigned task are complete (block 58). By including identifying information along with the forwarded message and processing results, additional overhead and delay associated with sending and processing separate control type messages between supporting processes and the control process are eliminated. That identifying information also eliminates the need for separate signaling to the controlling process C to specifv the identity and/or number of involved processes.
A specific example (i.e., non-limiting) implementation of the present invention is now described in conjunction with Figs. 5A-5C, 6, 7, and S. In this non-CA 02349706 2001-05-01 =
WO. 00/26765 PCT/SE99/01950 limiting example, the included information is an end token set S attached to each forwarded message. The end token set S contains one or more end tokens ei, where i 1, 2, 3, ..., that are associated with the message. Each end token el is composed of a unique token identifier (e. id) and- a number of output "branches" (e. n) from the s corresponding process to other supporting processes (block 62). Initially, the control process C sends a message with the end token set S to each output branch to one or more supporting processes. At this point, the end token set includes only the end token generated by the controlling process C (block 64).
Fig. 5B illustrates in flowchart form procedures for processing messages io received at each supporting process entitled "Process Message at P! "
(block 70). A
decision is made in block 72 regarding the number of output branches from the current process P to other supporting processes. If there is only one output branch, then the current process P sends the message M along with the token set S that was originally received by the current process Pi along with the message as processed by the current 15 process P to that single output branch (block 74). However, if there is more than one output branch from the current process P, the current process P defines a new unique token identifier e. id as well as the number of output branches e. n from the current process P to generate a new end token e! = (e.id + e.n~ (block 76). The current process P performs its portion of the data processing task (block 77). The current 20 process P then sends the message M, the processing results produced by the current process P; , and an end token set Si that equals the mathematical union of the end token of the current process ej with the end token set S;_ i received by the current process P
to just one of the output branches from the current process P(block 78). In addition, the current process P1 sends the received message M, the processing results produced ;5 by the current process P, , and an end token set S; contair,ing just the end token e; to all of the other output branches from the current process P(block 80).
Thus, only one of the plural output branches receives both the token set S;_i received by the current process P along with the message M as well as the end token ei in order to properly conduct the evaluation performed at the controlling process. In this example embodiment, the evaluation process is essentially an end token counting process. For each end token identifier ( e.id ), a counter is established in a COLTNT array managed by the controlling process C corresponding to the expected number of end tokens to arrive before the requested task has been completed by all of the involved supporting processors. If the entire set of end tokens, (i.e., the union of e;
and Sj_1), were to be transmitted to more than one output branch, then the controlling process C would receive duplicate end tokens thereby erroneously inflating the token count.
The flowchart in Fig. 5C illustrates a"Message Processing at C" routine performed at the controlling process C (block 19). As mentioned above, the controlling process C generates an array of counters COLTNT which counts a remaining number of end tokens for each e.id. When a message is received at the control process from a supporting process P, the control process C removes one end token from the end token set S which is attached with a received message to assure termination of the processing loop (block 92). A decision is made in block 94 if a corresponding counter has already been established in the COUNT array for the end token e.id in the end token set S. If so, the corresponding counter in the COLTNT array, i.e., COUNT( e. id ), is decremented by one (block 96). If not, the control process C inserts a counter corresponding to e. id into the count array and sets COUNT( e. id ) equal to e. n- 1. A decision is made in block 100 whether there are remaining tokens in the end token set S. If so, control returns to block 92. Otherwise, a decision is made in block 102 to determine if all of the established end token counter values in the COUNT array are zero. If not, the control process C waits for more messages from supporting processes (block 104). If all end token counter values are zero, then all necessary messages have arrived, and the task processing is finished (block 106).
The procedures outlined in Figs. 5A-5C are implemented in three example scenarios shown in Figs. 6, 7, and 8. Fig. 6 illustrates a simple example scenario in which nothing happens to the end token set S={ et } during the transmission between various processes since the message M is sent only to one output branch from each 5 process. Therefore, the COUNT array at the controlling process C is empty until the single message is received. Since the single message contains only one end token corresponding to e!, its corresponding counter has a value of el .n . Since the number of output branches _ el . n equals 1, the controlling process sets the starting value for COUNT( el . id ) in the COUNT array to (el. n- 1) which is equal to zero (block 98).
to Since all counter values in the COUNT array are zero, the controlling process C reau~~~
that all messages have been received and the task is completed.
A more complicated example where two copies of the messaQe M are output by supporting process Pt is shown in Fig. 7. Initially, the end token ei is generated by the controlling process C, where el n =1, since there is only one output branch corresponding to one copy of the message being forwarded from C to PI
.(Keep in mind that the end token identifier does not identify a particular process.) At process Pl the message M is sent to two output branches, one to process P2 and one to process P3. The message M on both of these branches contains the same end token e, identifying the current process Pl , and the number of output branches e, . n=
RF Qi 1F STPLRF tvrFn BY DI5JBMJITED PR F SSLS
FTF.I.D OF IM EMNTION
The present invention relates to perfornling tasks using distributed processes either in the context of a singlo data processor or in a multiprocessor context.
While the present invention finds advantageous application to any cooperative effort to perform a task, one example application is to database query evaluation in data rnanagement systems.
BACKGROUND AND SUMMARY OF THE INVENTION
In database managamcnt, data is organized and stored in electronically readable form for subsequent shared access by multiple computer users.
Database engines enable those users to submit queries addressing such data, which may be organized conceptually in relational, tabular, hierarchical or other forms, and to receive in response to a query an output known as an answer set. The following is an example is of a query. Assume there is a register of employees in a particular company. For e.aeh employee, there is stored (among other things) the employee's name, salary, and age.
One possible query is to "find all names of employees that have a salary of more than $20,000 and are less than 30 years old."
Under various circumstances, answer 9ets can take a significant amount of zo time to produce, and this problem rnay be significant. Therefore, database management systems often employ multiple processes operating on a single computer or multiple processors to perform a query by breaking each query request into interrelated tasks that can be executed by using multiple processes or processors. In otlier words, each process or processor performs some part of the execution of the query.
25 Multiprocesslprocessor systems, in general, are known. For example, U.S.
Patent No. 5,668,714 to Morikawa (assioned to Fujitsu) describes a multiprocessor apparatus baving plural processors in which each processor is assigned to a partic-ular process.
Unnecessary or excess processors are released from their assignment to a process, and if the number of processes assigned to the process is insufficient, one or more idle AMENDED SHEET
~
processors is assigned to the process. The query results produced from all of the cooperating query processes (i.e., query operators) are gathered and combined to generate the required query response/answer set. -The difficulty in a distributed query execution specifically, and in any s type of distributed processing system generally, is knowing when all of the intcrconnectcd and cooperating processes have completed processing of their respective portions of the overall task. Consider the example distributed processing scenario shown in Fig. 1. A user terminal 10 communicates with a computer system 12 by way of a user iAterface 14. In the context of a database management systan, the computer i o system 12 may also be connected to a database 16. A task (such as a database query) from the user interface 14 is provided for distributed execution to a controlling process C which then passes the task (or portions tbereot) to supporting processes P1, P2, P3, and P4 as shown. Each process P1-P4 executes some part (or its own portion) of the task. More specibcally, controlling process C sends a measage defining or 15 otherwise related to the task to the first process P1. rirstprocess P1 performs its part of the task and sends those partial task results along with the message it received from the controlling pxocess C both to supporting processes P2 and P3. The supporting processes P2 and P3 perform their respective parts of the task and send their respective results along with the message each received from the process P1, which includes the 20 results from the process P1, to supporting processes.
The completed task reaches the controlling process C in the form of two messages, one from the chain C--),P1-3P2--~C and one from the chain C-4P 1-aP3--->P4-3C. The problem at this point is for the controlling process C to determine when it has received all messages from all of the agent processes involved in 25 performing the task. This problem is complicated by the fact that while the contrailing process knows about the first supporting process Pi, it does not necessarily know the identity of all supporting processes that contributed to the completion of the task. As a result, the controlling process C does not even know how many process messages to expect.
AMENDED SHEET
One possible solution to this problem is for all of the supporting processes P to inform the controlling process C of their identities and then to send a message from the controlling process C to each of the supporting processes P(i.e., Pl - P4 in Fig. 1) requesting that each of the supporting processes communicate with the controlling process C when they have completed its portion of the task.
Each supporting process P then sends another message to the controlling process C
when it has completed its respective task portion. One drawback of this solution is that it requires that the identity of all the supporting processes that will be involved in executing some portion of the task be known in advance by C. This requirement is not io always easy or desirable to meet. Another significant drawback of this possible solution is that all of the overhead-type signaling between the controlling process C
and the supporting processes is time consuming and inefficient.
It is an object of the present invention to provide efficient distributed processing of a task in a timely fashion.
It is an object of the present invention to perform distributed processing of a task using plural processes without the need for overhead signaling between various processes.
It is an object of the present invention for a controlling process in a distributed processing environment to be able to deterniine from the messages received 2o from distributed processes executing a portion of the task when the task is complete without having specialized signaling between the controlling process and each supporting process.
It is a further object of the present invention to provide an efficient distributed processing technique where the controlling process does not even need to ^s know the number or the identities of supporting processes which will participate in the distributed execution of a task.
The present invention solves these problems and satisfies these and other objects. Rather than sending control messages back and forth between the controlling process and each supporting process, each process includes some type of identifying information that it forwards to a supporting process along with a substantive task =
message. Ultimately, those messages with the identifying information reach the controlling process. The controlling process then deduces from the received identifying information whether all of the messages from all processes involved in the task have been received. If the controlling process deduces they have, the task is complete.
In one example embodiment, as a message related to a data processing io task is passed between those processes involved in performing the data processing task.
Each of those processes performs some function related to the task and passes an "end token" along with the message -- as modified by the function performed by that process -- to another of the involved processes. The control process determines that the data processinD task is finished using the end tokens received along with the distributed processing results from the involved processes. Each end token includes a unique identifier and the number of copies of the message forwarded by the corresponding process and is used by the control process to generate an arrav of count values. A count value is established for each unique end token based on the number of inessage copies forwarded by the corresponding process. When all of the count values are decremented to zero, the controlling process determines that the messages from all involved processes have arrived and processing is complete.
The invention has advantageous application to database management, and in particular, to database query evaluation. However, the present invention is not limited to database management or query evaluation and may be employed advantageously in any application where processes cooperate to achieve an overall goal.
The processes may be implemented in the same computer or at separate computers. In a single computer case, the processes may communicate for example using the message passing functionality of the computer's operating system. In a multi-computer case, each computer may communicate over an appropriate transmission medium such as a = shared memory, a local area network, the Internet, etc.
BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing and other objects, features, and advantages of the invention 5 will be apparent from the following description of preferred example embodiments as illustrated in the accompanying drawings in which-reference characters refer to the same parts throughout the various views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.
Fig. 1 is a diagram of a distributed process used to execute a data io processing task;
Fig. 2 shows a multi-processor, network-based distributed data processing system that may be used to execute a data processing task;
Fig. 3 is another configuration of a multi-processor data processing system that may be used to execute a data processing task where the processors are connected by a data bus and communicate using a shared memory;
Fig. 4 is a flowchart diagram illustrating procedures for evaluating the execution of a data processing request in accordance with an example embodiment of the present invention;
Figs. 5A-5C are flowchart diagrams illustrating various procedures for implementing the present invention in another specific, example embodiment of the present invention; and Figs. 6-8 illustrate example operations of the present invention -implemented using the specific example embodiment of Figs. 5A-5C in increasingly more complex distributed processing situations.
DETAILED DESCRIPTION OF THE INVENTION
In the following description, for purposes of explanation and not Iimitation, specific details are set forth, such as particular embodiments, process flows, and techniques, in order to provide a thorough understanding of the present invention.
However, it will be apparent to one skilled in the art that the present invention may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known methods, systems, and devices are omitted so as not to obscure the description of the present invention with unnecessary detail.
The present invention may be implemented in a variety of contexts. For example, the present invention may be implemented in a single computer based system such as that shown in Fig. 1 where distributed software processes are employed to cooperatively execute a task. Those processes communicate using the computer's operating software. In addition, the present invention may be applied to a multi-processor environment. One example multi-processor environment is shown in Fig. 2 where multiple nodes (1-4) identified with reference numerals 20, 22, 24, and 26 are connected by way of a network 30 such as Ethernet, Internet, etc. Each of the nodes 1-4 includes a data processor that performs some portion of the requested data processing task. The node data processors communicate using an appropriate communications protocol over the network 30. Fig. 3 shows another example multi-processor configuration where CPUs 1, 2, ... N corresponding to reference numerals 32, 34, and 36, respectively, are coupled to a shared memory 40 over a data bus 38.
However, these example applications are in no way limiting since the present invention may be used in any situation where there is a set of "things" sending messages, packets, etc. to each other in directed, acyclic manner.
Filz. 4 outlines example steps ior determining wiiether a data processing request has been completed by distributed processes as set forth in the Request Evaluation procedures (block 50). For ease of description only and in no way limiting, the present invention is described in terms of "processes" which may be implemented using one or more computers or other types of electronic data processing circuitry.
Initially, a task is assigned to a control process (C) for distributed or otherwise cooperative processing by a plurality of processes (block 52).
A message related to the task to be accomplished is sent from control process C to one or more supporting processes P w,hich assist in accomplishing the requested data processing task (block 54). Each supporting process P receives its own copy of the message from C and performs some proccssing function associated with the io message. After processing, each supporting processor forwards the received message along with the results of its processing to another supporting process. While in this example the message passed between processes is the same, different messages may also be passed between processes.
A supporting process P includes some type of identifying information, (e.g., a token as explained hereafter), with the message along with the results of the data processing performed (related to the assigned task) by that process (block 56). The control process C uses that identifying information collected from messages received from supporting processes to determine whether all processes performed by all of the supporting processes P involved in executing the assigned task are complete (block 58). By including identifying information along with the forwarded message and processing results, additional overhead and delay associated with sending and processing separate control type messages between supporting processes and the control process are eliminated. That identifying information also eliminates the need for separate signaling to the controlling process C to specifv the identity and/or number of involved processes.
A specific example (i.e., non-limiting) implementation of the present invention is now described in conjunction with Figs. 5A-5C, 6, 7, and S. In this non-CA 02349706 2001-05-01 =
WO. 00/26765 PCT/SE99/01950 limiting example, the included information is an end token set S attached to each forwarded message. The end token set S contains one or more end tokens ei, where i 1, 2, 3, ..., that are associated with the message. Each end token el is composed of a unique token identifier (e. id) and- a number of output "branches" (e. n) from the s corresponding process to other supporting processes (block 62). Initially, the control process C sends a message with the end token set S to each output branch to one or more supporting processes. At this point, the end token set includes only the end token generated by the controlling process C (block 64).
Fig. 5B illustrates in flowchart form procedures for processing messages io received at each supporting process entitled "Process Message at P! "
(block 70). A
decision is made in block 72 regarding the number of output branches from the current process P to other supporting processes. If there is only one output branch, then the current process P sends the message M along with the token set S that was originally received by the current process Pi along with the message as processed by the current 15 process P to that single output branch (block 74). However, if there is more than one output branch from the current process P, the current process P defines a new unique token identifier e. id as well as the number of output branches e. n from the current process P to generate a new end token e! = (e.id + e.n~ (block 76). The current process P performs its portion of the data processing task (block 77). The current 20 process P then sends the message M, the processing results produced by the current process P; , and an end token set Si that equals the mathematical union of the end token of the current process ej with the end token set S;_ i received by the current process P
to just one of the output branches from the current process P(block 78). In addition, the current process P1 sends the received message M, the processing results produced ;5 by the current process P, , and an end token set S; contair,ing just the end token e; to all of the other output branches from the current process P(block 80).
Thus, only one of the plural output branches receives both the token set S;_i received by the current process P along with the message M as well as the end token ei in order to properly conduct the evaluation performed at the controlling process. In this example embodiment, the evaluation process is essentially an end token counting process. For each end token identifier ( e.id ), a counter is established in a COLTNT array managed by the controlling process C corresponding to the expected number of end tokens to arrive before the requested task has been completed by all of the involved supporting processors. If the entire set of end tokens, (i.e., the union of e;
and Sj_1), were to be transmitted to more than one output branch, then the controlling process C would receive duplicate end tokens thereby erroneously inflating the token count.
The flowchart in Fig. 5C illustrates a"Message Processing at C" routine performed at the controlling process C (block 19). As mentioned above, the controlling process C generates an array of counters COLTNT which counts a remaining number of end tokens for each e.id. When a message is received at the control process from a supporting process P, the control process C removes one end token from the end token set S which is attached with a received message to assure termination of the processing loop (block 92). A decision is made in block 94 if a corresponding counter has already been established in the COUNT array for the end token e.id in the end token set S. If so, the corresponding counter in the COLTNT array, i.e., COUNT( e. id ), is decremented by one (block 96). If not, the control process C inserts a counter corresponding to e. id into the count array and sets COUNT( e. id ) equal to e. n- 1. A decision is made in block 100 whether there are remaining tokens in the end token set S. If so, control returns to block 92. Otherwise, a decision is made in block 102 to determine if all of the established end token counter values in the COUNT array are zero. If not, the control process C waits for more messages from supporting processes (block 104). If all end token counter values are zero, then all necessary messages have arrived, and the task processing is finished (block 106).
The procedures outlined in Figs. 5A-5C are implemented in three example scenarios shown in Figs. 6, 7, and 8. Fig. 6 illustrates a simple example scenario in which nothing happens to the end token set S={ et } during the transmission between various processes since the message M is sent only to one output branch from each 5 process. Therefore, the COUNT array at the controlling process C is empty until the single message is received. Since the single message contains only one end token corresponding to e!, its corresponding counter has a value of el .n . Since the number of output branches _ el . n equals 1, the controlling process sets the starting value for COUNT( el . id ) in the COUNT array to (el. n- 1) which is equal to zero (block 98).
to Since all counter values in the COUNT array are zero, the controlling process C reau~~~
that all messages have been received and the task is completed.
A more complicated example where two copies of the messaQe M are output by supporting process Pt is shown in Fig. 7. Initially, the end token ei is generated by the controlling process C, where el n =1, since there is only one output branch corresponding to one copy of the message being forwarded from C to PI
.(Keep in mind that the end token identifier does not identify a particular process.) At process Pl the message M is sent to two output branches, one to process P2 and one to process P3. The message M on both of these branches contains the same end token e, identifying the current process Pl , and the number of output branches e, . n=
2 from process Pi. However, the end token el is only sent in one of the messages forwarded by process Pl as described above with respect to block 76 in Fig. 5B. Since processes P, and P3 have only one output branch, they do not attach a new end token but rather simply forward the end token set S received, i.e., either {e, e, } or (e-, }
along with the message.
With re(rard to receiving messages at the controlling process C, the following sets of end tokens arrive in any order. If they arrive in this order {e: } and {ele2 }, the controlling process C inserts e, . id into the COUNT array and sets the counter value of COUNT (e, . id ) equal to e, . n-1, which in this example is equal to 1.
When the next token set {ete, } arrives, the controlling process C sets the counter value of COUNT (el.id) = el.n -1 which equals 0. As already described, the COLTNT e2 .id s is currendy 1, so the end token e2 in the received end token set {ele2 }
decrements COUNT (e, . id ) to zero. Since all of the counters in the COUNT array have zero values, the controlling process C determines that there are no further messages to be received, and that the task is complete. If the end token sets arrive in the opposite order, i.e., {eie2 } followed by {e2 }, a similar result is attained.
Fig. 8 illustrates an even more complicated example with multiple supporting processes having plural output branches. However, similar procedures are followed with equal success. The controlling process C sends a message to process Pl, and Pl sends message copies to supporting processes P, , P3, and P4. The initial message from controlling process C includes only one end token in the set {e, }.
Process Pl then generates a new end token e, with e, . n = 3 since there are three output branches from process P,. In one of the branches, i.e., the branch to process P, , that set of end tokens is expanded to include end token e, so that S=[ele, }.
However, the other two output branches include an end token set with only the new end token {e2 } .
The process P, outputs its message to two branches received by processes P5 and P6. Therefore, the end token e3 is generated bv process P, with e3 . n = 2 being attached to the message sent to those two branches. The end token is also inserted into the received end token set to generate { e~ e, e3 } which is then passed en to only supportino process P5. Processes P5 ar.d P6 botli pass the end token sets which they received from process PZ unchanged since they each have only one output branch. P4 also only passes its received end token having just one output branch.
Similar end token handling described for process P, , P4, PS , and P6 is performed by processes P3, P7, P8, and P9 . .
The controlling process C will ulti.m.ately receives messages with the various end token sets attached corresponding to:
(a) - {el e2 e3 }, (b) - {eZ e4 }, (c) - {e2 }, (d) - {e3 }, and (e) - {e4 } .
These end token sets may arrive at the controlling process C in any order. Table 1 below shows one order of airival and Table 2 below shows a reversed order of arrival:
Table 1 Message sequence Token set in the message Expected number of End number Tokens el e: e3 e4 1 {ele,e3} 0 2 1 2 {e, e. } 0 1 1 1 3 {e,} 0 0 1 1 4 {e3 } 0 0 0 1 5 {e4} 0 0 0 0 Table 2 Message sequence Token set in the message Expected number of End number Tokens ei e, e3 e4 1 {e4 } I
2 {e3} 1 1 3 {e2} 2 1 1 4 {eZe4 } 1 1 0 {eIe2e3 } 0 0 0 0 While the present invention has been described with respect to a particular embodiment, those skilled in the art will recognize that the present invention is not limited to the specific embodiments described and illustrated herein.
Different formats, embodiments, and adaptations besides those shown and described as well as many 5 modifications, variations, and equivalent arrangements may also be used to implement the invention. Therefore, while the present invention has been described in relation to its preferred embodiments, it is to be understood that this disclosure is only illustrative and exemplary of the present invention and is merely for the purposes of providing a full and enabling disclosure of the invention. Accordingly, it is intended that the io invention be lirnited only bv the spirit and scope of the claims appended hereto.
along with the message.
With re(rard to receiving messages at the controlling process C, the following sets of end tokens arrive in any order. If they arrive in this order {e: } and {ele2 }, the controlling process C inserts e, . id into the COUNT array and sets the counter value of COUNT (e, . id ) equal to e, . n-1, which in this example is equal to 1.
When the next token set {ete, } arrives, the controlling process C sets the counter value of COUNT (el.id) = el.n -1 which equals 0. As already described, the COLTNT e2 .id s is currendy 1, so the end token e2 in the received end token set {ele2 }
decrements COUNT (e, . id ) to zero. Since all of the counters in the COUNT array have zero values, the controlling process C determines that there are no further messages to be received, and that the task is complete. If the end token sets arrive in the opposite order, i.e., {eie2 } followed by {e2 }, a similar result is attained.
Fig. 8 illustrates an even more complicated example with multiple supporting processes having plural output branches. However, similar procedures are followed with equal success. The controlling process C sends a message to process Pl, and Pl sends message copies to supporting processes P, , P3, and P4. The initial message from controlling process C includes only one end token in the set {e, }.
Process Pl then generates a new end token e, with e, . n = 3 since there are three output branches from process P,. In one of the branches, i.e., the branch to process P, , that set of end tokens is expanded to include end token e, so that S=[ele, }.
However, the other two output branches include an end token set with only the new end token {e2 } .
The process P, outputs its message to two branches received by processes P5 and P6. Therefore, the end token e3 is generated bv process P, with e3 . n = 2 being attached to the message sent to those two branches. The end token is also inserted into the received end token set to generate { e~ e, e3 } which is then passed en to only supportino process P5. Processes P5 ar.d P6 botli pass the end token sets which they received from process PZ unchanged since they each have only one output branch. P4 also only passes its received end token having just one output branch.
Similar end token handling described for process P, , P4, PS , and P6 is performed by processes P3, P7, P8, and P9 . .
The controlling process C will ulti.m.ately receives messages with the various end token sets attached corresponding to:
(a) - {el e2 e3 }, (b) - {eZ e4 }, (c) - {e2 }, (d) - {e3 }, and (e) - {e4 } .
These end token sets may arrive at the controlling process C in any order. Table 1 below shows one order of airival and Table 2 below shows a reversed order of arrival:
Table 1 Message sequence Token set in the message Expected number of End number Tokens el e: e3 e4 1 {ele,e3} 0 2 1 2 {e, e. } 0 1 1 1 3 {e,} 0 0 1 1 4 {e3 } 0 0 0 1 5 {e4} 0 0 0 0 Table 2 Message sequence Token set in the message Expected number of End number Tokens ei e, e3 e4 1 {e4 } I
2 {e3} 1 1 3 {e2} 2 1 1 4 {eZe4 } 1 1 0 {eIe2e3 } 0 0 0 0 While the present invention has been described with respect to a particular embodiment, those skilled in the art will recognize that the present invention is not limited to the specific embodiments described and illustrated herein.
Different formats, embodiments, and adaptations besides those shown and described as well as many 5 modifications, variations, and equivalent arrangements may also be used to implement the invention. Therefore, while the present invention has been described in relation to its preferred embodiments, it is to be understood that this disclosure is only illustrative and exemplary of the present invention and is merely for the purposes of providing a full and enabling disclosure of the invention. Accordingly, it is intended that the io invention be lirnited only bv the spirit and scope of the claims appended hereto.
Claims (23)
1. A method in which a data processing request is processed by a plurality of supporting processes (P i), comprising the steps of:
providing the data processing request to a control process (C);
in response to the data processing request, defining at the control process (C) a set (S) of indicators including an indicator (ei) dependent on the number of output branches from the control process (C); and outputting from each output branch a message with a portion of the data processing request and the set (S) of indicators (e i);
receiving at supporting processes (P i) a message with a portion of the data processing request and a set of indicators (e i);
processing at said supporting processes (P i) a portion of the data processing request;
defining at each of said supporting processes (P i) a new indicator (e i) dependent on its number of output branches;
outputting from one of the output branches of each said supporting processes (P i) message with its processing results and a set (S i) of indicators that includes the union of the new indicator (e i) and the set (S i-1) of indicators received from the preceding process;
outputting from all of any other output branches of each said supporting processes (P i) a message with its processing results and a set (S i) of indicators including said new indicator (e i);
receiving at the control process (C) messages from supporting processes with sets (S i) of indicators, and determining dependent on the received sets (S i) of indicators if messages from each of the supporting processes (P i) have been received and the data processing request thereby is completed.
providing the data processing request to a control process (C);
in response to the data processing request, defining at the control process (C) a set (S) of indicators including an indicator (ei) dependent on the number of output branches from the control process (C); and outputting from each output branch a message with a portion of the data processing request and the set (S) of indicators (e i);
receiving at supporting processes (P i) a message with a portion of the data processing request and a set of indicators (e i);
processing at said supporting processes (P i) a portion of the data processing request;
defining at each of said supporting processes (P i) a new indicator (e i) dependent on its number of output branches;
outputting from one of the output branches of each said supporting processes (P i) message with its processing results and a set (S i) of indicators that includes the union of the new indicator (e i) and the set (S i-1) of indicators received from the preceding process;
outputting from all of any other output branches of each said supporting processes (P i) a message with its processing results and a set (S i) of indicators including said new indicator (e i);
receiving at the control process (C) messages from supporting processes with sets (S i) of indicators, and determining dependent on the received sets (S i) of indicators if messages from each of the supporting processes (P i) have been received and the data processing request thereby is completed.
2. The method of claim 1, wherein each of the supporting processes (P i) performs a part of the data processing request.
3. The method of claim 1, wherein each of the supporting processes (P i) forwards the results of its performed part along with its output message.
4. The method of claim 1, wherein each indicator is a token that includes a token identifier (e.id) associated with the corresponding process, and a number (e.n) of output branches from the respective process.
5. The method of claim 1, wherein each supporting process (P i) forwards a copy of the message (M) from the control process(C) along with the results of its processing to a subsequent process.
6. The method of claim 5, wherein each indicator is a token that includes a token identifier (e.id) associated with the corresponding process , and a number (e.n) of copies of the message forwarded by the corresponding supporting process to a corresponding number of other supporting processes.
7. The method of claim 4 or 6, further comprising the step of establishing a count array (COUNT (e.id) managed by the control process for each identifier corresponding to an expected number of identifiers to arrive before the requested task has been completed by all of the supporting processes.
8. The method of claim 7, further comprising the steps of decrementing each count array when the message is received at the control process from the corresponding supporting process, and determining that the requested data processing task is complete when each count array is zero.
9. The method of claim 1, wherein the data processing request is a database query and the supporting processes (P i) are query processes.
10. The method of claim 1, wherein the supporting processes communicate using a message passing function of an operating system software.
11. The method of claim 1, wherein the supporting processes are distributed at remotely-located nodes (20-26) that communicate over a network (30).
12. The method in claim 1, wherein the supporting processes are distributed at data processors (32-36) connected by way of a databus (38) to a shared memory (40).
13: The method of claim 1, wherein after information has been processed by the supporting processes (P i), the information is not returned to these supporting processes.
14. A distributed data processing system for co-operative data processing, comprising:
a co-ordinator process (C) for defining a set (S) of indicators including an indicator (e i) dependent on the number of output branches from the control process (C);
and outputting from each output branch a message with a portion of the data processing request and the set (S) of indicators (e i);
a plurality of supporting processes (Pi), each supporting process receiving a message with a portion of the data processing request and a set of indicators (e i);
processing a portion of the data processing request; defining a new indicator (e i) dependent on its number of output branches; outputting from one of its output branches a message with its processing results and a set (S i) of indicators that includes the union of the new indicator (e i) and the set (S i-1) of indicators received from the preceding process;
outputting from all of any other output branches a message with its processing results and a set (S) of indicators including said new indicator (e i);
wherein the co-ordinator process (C)receives messages from supporting processes with sets (S i) of indicators and determines dependent on the received sets (S
i) of indicators if messages from each of the supporting processes (Pi) have been received and the data processing function thereby is complete.
a co-ordinator process (C) for defining a set (S) of indicators including an indicator (e i) dependent on the number of output branches from the control process (C);
and outputting from each output branch a message with a portion of the data processing request and the set (S) of indicators (e i);
a plurality of supporting processes (Pi), each supporting process receiving a message with a portion of the data processing request and a set of indicators (e i);
processing a portion of the data processing request; defining a new indicator (e i) dependent on its number of output branches; outputting from one of its output branches a message with its processing results and a set (S i) of indicators that includes the union of the new indicator (e i) and the set (S i-1) of indicators received from the preceding process;
outputting from all of any other output branches a message with its processing results and a set (S) of indicators including said new indicator (e i);
wherein the co-ordinator process (C)receives messages from supporting processes with sets (S i) of indicators and determines dependent on the received sets (S
i) of indicators if messages from each of the supporting processes (Pi) have been received and the data processing function thereby is complete.
15. The distributed data processing system of claim 14, wherein the supporting processes and the co-ordinator process are executed using a single data processor and the processes communicate using a message passing part of an operating system executed by a data processor.
16. The distributed data processing system of claim 14, wherein the distributed data processing system is a database system and the data processing function is a database query.
17. The distributed data processing system of claim 14, wherein the supporting processes and the co-ordinator process each correspond to respective data processors (20-26) connected by a network (30).
18. The distributed data processing system of claim 14, wherein the supporting processes and the co-ordinator process each correspond to respective data processors (32-36) that communicate through a shared memory (40).
19. The distributed data processing system of claim 14, wherein the co-ordinator process determines that the data processing function is finished when all of the tokens associated with any of the supporting processes are received by the co-ordinator process.
20. The distributed data processing system of claim 14, wherein each token includes an identifier (e.id) associated with a corresponding supporting process and a number corresponding to the number (e.n) of processes to which the token is passed by its corresponding process.
21. The distributed data processing system of claim 14, wherein each supporting process forwards a token set (8) to another supporting process, with one or more supporting processes adding a token to the token set.
22. The distributed data processing system of claim 14, further comprising:
a count array (COUNT (e.id) managed by the co-ordinator process for each token corresponding to an expected number of tokens to arrive before the data processing function has been completed.
a count array (COUNT (e.id) managed by the co-ordinator process for each token corresponding to an expected number of tokens to arrive before the data processing function has been completed.
23. The distributed data processing system of claim 22, wherein the co-ordinator process decrements each count array when the message is received at the co-ordinator process from the corresponding supporting process, and determines that the data processing function is complete when each count array is zero.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/185,079 US6604122B1 (en) | 1998-11-03 | 1998-11-03 | Method and apparatus for evaluating a data processing request performed by distributed processes |
| US09/185,079 | 1998-11-03 | ||
| PCT/SE1999/001950 WO2000026765A2 (en) | 1998-11-03 | 1999-10-29 | Method and apparatus for evaluating a data processing request performed by distributed processes |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2349706A1 CA2349706A1 (en) | 2000-05-11 |
| CA2349706C true CA2349706C (en) | 2009-05-26 |
Family
ID=22679489
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002349706A Expired - Lifetime CA2349706C (en) | 1998-11-03 | 1999-10-29 | Method and apparatus for evaluating a data processing request performed by distributed processes |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US6604122B1 (en) |
| EP (1) | EP1127310B1 (en) |
| JP (1) | JP2002529808A (en) |
| KR (1) | KR20010085985A (en) |
| AU (1) | AU1514800A (en) |
| BR (1) | BR9914991A (en) |
| CA (1) | CA2349706C (en) |
| DE (1) | DE69922832T2 (en) |
| WO (1) | WO2000026765A2 (en) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| USRE42153E1 (en) | 2000-03-30 | 2011-02-15 | Hubbard Edward A | Dynamic coordination and control of network connected devices for large-scale network site testing and associated architectures |
| US8010703B2 (en) | 2000-03-30 | 2011-08-30 | Prashtama Wireless Llc | Data conversion services and associated distributed processing system |
| US20090216641A1 (en) | 2000-03-30 | 2009-08-27 | Niration Network Group, L.L.C. | Methods and Systems for Indexing Content |
| US20010027467A1 (en) * | 2000-03-30 | 2001-10-04 | Anderson David P. | Massively distributed database system and associated method |
| US20010039497A1 (en) * | 2000-03-30 | 2001-11-08 | Hubbard Edward A. | System and method for monitizing network connected user bases utilizing distributed processing systems |
| US7406511B2 (en) * | 2002-08-26 | 2008-07-29 | International Business Machines Corporation | System and method for processing transactions in a multisystem database environment |
| US7800631B2 (en) | 2003-03-18 | 2010-09-21 | Qualcomm Incorporated | Triangle rendering using direct evaluation |
| GB0422007D0 (en) * | 2004-10-05 | 2004-11-03 | Ibm | Method and system for identifying a complete response to a request |
| WO2008118613A1 (en) * | 2007-03-01 | 2008-10-02 | Microsoft Corporation | Executing tasks through multiple processors consistently with dynamic assignments |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4445171A (en) * | 1981-04-01 | 1984-04-24 | Teradata Corporation | Data processing systems and methods |
| US5297255A (en) | 1987-07-28 | 1994-03-22 | Hitachi, Ltd. | Parallel computer comprised of processor elements having a local memory and an enhanced data transfer mechanism |
| CA2078315A1 (en) | 1991-09-20 | 1993-03-21 | Christopher L. Reeve | Parallel processing apparatus and method for utilizing tiling |
| US5459860A (en) * | 1992-10-05 | 1995-10-17 | International Business Machines Corporation | Computerized system and process for managing a distributed database system |
| JPH0784973A (en) | 1993-09-16 | 1995-03-31 | Fujitsu Ltd | Unit and method for multiprocessing processor control |
| US6330582B1 (en) * | 1994-03-21 | 2001-12-11 | International Business Machines Corporation | Apparatus and method enabling a client to control transaction message traffic between server and client processes |
| US5826265A (en) * | 1996-12-06 | 1998-10-20 | International Business Machines Corporation | Data management system having shared libraries |
-
1998
- 1998-11-03 US US09/185,079 patent/US6604122B1/en not_active Expired - Lifetime
-
1999
- 1999-10-29 JP JP2000580080A patent/JP2002529808A/en active Pending
- 1999-10-29 CA CA002349706A patent/CA2349706C/en not_active Expired - Lifetime
- 1999-10-29 WO PCT/SE1999/001950 patent/WO2000026765A2/en active IP Right Grant
- 1999-10-29 KR KR1020017005459A patent/KR20010085985A/en not_active Application Discontinuation
- 1999-10-29 BR BR9914991-5A patent/BR9914991A/en not_active Application Discontinuation
- 1999-10-29 EP EP99957447A patent/EP1127310B1/en not_active Expired - Lifetime
- 1999-10-29 AU AU15148/00A patent/AU1514800A/en not_active Abandoned
- 1999-10-29 DE DE69922832T patent/DE69922832T2/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| AU1514800A (en) | 2000-05-22 |
| WO2000026765A3 (en) | 2000-10-05 |
| JP2002529808A (en) | 2002-09-10 |
| EP1127310A2 (en) | 2001-08-29 |
| DE69922832T2 (en) | 2005-12-15 |
| BR9914991A (en) | 2001-07-24 |
| EP1127310B1 (en) | 2004-12-22 |
| KR20010085985A (en) | 2001-09-07 |
| US6604122B1 (en) | 2003-08-05 |
| DE69922832D1 (en) | 2005-01-27 |
| CA2349706A1 (en) | 2000-05-11 |
| WO2000026765A2 (en) | 2000-05-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1949595B1 (en) | Method for the construction and execution of a distributed workflow in a communication system | |
| EP0169455B1 (en) | Non-unique names for broadcast messages | |
| US20080133668A1 (en) | Managing intended group membership using domains | |
| CA2503597A1 (en) | Method and apparatus for unique address assignment, node self-identification and topology mapping for a directed acyclic graph | |
| JPH07325790A (en) | Decentralized computer system and method for processing of ambiguous identifier by said system | |
| JPH0535903B2 (en) | ||
| WO2014194452A1 (en) | Message publishing and subscribing method and apparatus | |
| US20070016910A1 (en) | A Bridge for Linking Two Publish/Subscribe Message Brokers | |
| CA2349706C (en) | Method and apparatus for evaluating a data processing request performed by distributed processes | |
| KR100436471B1 (en) | Apparatus and method for communicating between computer systems using a sliding send window for ordered messages in a clustered computing environment | |
| CN109802951B (en) | Message forwarding method, device and storage device | |
| JPH1196159A (en) | Hypertext editing device | |
| Johri | Optimality of the shortest line discipline with state-dependent service rates | |
| US20040010538A1 (en) | Apparatus and method for determining valid data during a merge in a computer cluster | |
| US20030018606A1 (en) | Revocation of tokens without communication between the token holders and the token server | |
| US20030202522A1 (en) | System for concurrent distributed processing in multiple finite state machines | |
| US6925582B2 (en) | Forwarding of diagnostic messages in a group | |
| WO2004057469A1 (en) | A distributed object processing system and method | |
| JP2002141918A (en) | Method and system for avoiding starvation in computer network | |
| Esfahanian et al. | A distributed broadcast algorithm for binary De Bruijn networks | |
| Goscinski et al. | Message passing and RPC-based interprocess communication mechanisms in the RHODOS microkernel | |
| JPS63167938A (en) | Signal processing apparatus and method | |
| JPH02222336A (en) | Computer address managing system | |
| JPH0991234A (en) | Work flow system | |
| JPH0836547A (en) | Schedule device for transaction in on-line system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKEX | Expiry |
Effective date: 20191029 |