CN112199205B - Program communication method between heterogeneous platforms - Google Patents
Program communication method between heterogeneous platforms Download PDFInfo
- Publication number
- CN112199205B CN112199205B CN201910617450.8A CN201910617450A CN112199205B CN 112199205 B CN112199205 B CN 112199205B CN 201910617450 A CN201910617450 A CN 201910617450A CN 112199205 B CN112199205 B CN 112199205B
- Authority
- CN
- China
- Prior art keywords
- program
- call
- platform
- call request
- data interaction
- 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.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements 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/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/544—Buffers; Shared memory; Pipes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements 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/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/133—Protocols for remote procedure calls [RPC]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/548—Queue
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 Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Computer And Data Communications (AREA)
Abstract
The application relates to a program communication method among heterogeneous platforms, which introduces respective data interaction processes on each platform, a platform program puts a call request into a call buffer area, the call request is acquired by the data interaction processes, remote communication is carried out between the call request and programs of other platforms, and a call result is acquired and returned to the platform program. The method simplifies the platform program design and improves the program operation efficiency.
Description
[ field of technology ]
The application belongs to the field of computers, and particularly relates to a program communication method between heterogeneous platforms.
[ background Art ]
The existing computer has a plurality of different heterogeneous platforms, and with the development of networks and information technologies, the different platforms need to communicate through the networks. A typical situation is that a program on one platform requires remote invocation of a program on another platform, which requires program communication between the different platforms. The existing inter-platform program communication method needs the program itself to know the condition of the opposite side platform and carries out corresponding processing based on the type of the opposite side platform, which brings certain difficulty to the design and writing of the program. In addition, inter-platform telecommunications may cause problems with time-outs.
[ application ]
In order to solve the above problems in the prior art, the present application provides a program communication method between heterogeneous platforms.
The technical scheme adopted by the application is as follows:
a method of program communication between heterogeneous platforms, comprising the steps of:
(1) Program PA running on platform A generates a call request, wherein the call request comprises an identifier of platform B, an identifier and interface of program PB, a call parameter and a call request identifier; program PB is the program to be called by program PA, and runs on platform B;
(2) The program PA writes the call request into a call buffer area of the platform A;
(3) The data interaction process CA running on the platform A reads and analyzes the call request from the call buffer area to acquire the related information of the call request;
(4) The data interaction process CA formats the related information of the call request according to the related requirements of the platform B to generate a second call request, wherein the second call request also comprises an identifier of the platform A;
(5) The data interaction process CA sends the second call request to the platform B, and the platform B stores the received second call request into a receiving buffer;
(6) The data interaction process CB running on the platform B reads the second call request from the receiving buffer area, creates a call thread, calls a corresponding interface of the program PB based on information in the second call request, and transmits the call parameter;
(7) The program PB receives calling based on the calling parameters, generates corresponding processing results, returns the processing results to the calling thread, and stores the processing results and corresponding calling request identifiers in a result cache area of the platform B;
(8) The data interaction process CB reads the processing result and the calling request identifier from the result cache area, the data interaction process CB determines a platform A corresponding to the calling request according to the calling request identifier, formats the processing result according to the related requirement of the platform A, and generates a second processing result meeting the requirement of the platform A, wherein the second processing result comprises the formatting result of the processing result and the calling request identifier;
(9) The data interaction process CB sends the second processing result to the platform A, and the platform A stores the received second processing result into a result return buffer area;
(10) The data interaction process CA reads the second processing result from the result return buffer area, and determines a program PA corresponding to the second processing result according to a calling request identifier in the second processing result;
(11) The data interaction process CA sends the second processing result to the program PA.
Further, the call request also includes a defined time parameter T, the defined time parameter T represents the maximum acceptable waiting time for the PA to make a remote call, and the system records the time T when the call request is written into the call buffer 0 ;
When the data interaction process CA reads the call request in step 3, the CA calculates the remaining time T 1 =T 0 +T-T now Wherein T is now Is the current time;
the data interaction process CA calculates the minimum expected time T of the processing result min T, i.e min =T 2 +T 3 The method comprises the steps of carrying out a first treatment on the surface of the Wherein T is 2 Is the journey time of data back and forth between platform A and platform B, T 3 Is a predefined minimum time for representing program PB to process the call;
data interaction process CA judges T 1 And T is min Is a size relationship of (a):
if T 1 <T min The data interaction process CA directly returns a failure result to the program PA;
if T 1 ≥T min The data interaction process CA continues to execute the subsequent steps, and the CA starts a timer which starts to count from 0, and when the timer reaches T 1 And when the CA does not acquire the corresponding second processing result, the CA returns a timeout result to the program PA, and informs the program PA that the returned result is timeout.
Further, the call buffer is a specially opened storage area in the platform a memory, the call buffer is divided into a plurality of segments in advance, each segment stores a call request, and when the program PA writes the call request into one of the segments, the identifier of the program PA is written at the same time, and the identifier indicates that the segment is occupied by the program PA.
Further, the call buffer is controlled by the system, allowing each program to write into the empty segment, but not allowing each program to read the data of each call request in the call buffer, and only allowing the data interaction process CA to read the call request data.
Further, after the CA sends the second call request, the CA clears the corresponding call request in the call buffer.
Further, the receiving buffer area is a storage area opened up in the memory of the platform B and is used for storing the received call request, the receiving buffer area is divided into a plurality of segments, each segment stores a received call request, and the receiving buffer area can only be read by the data interaction process CB on the platform B.
Further, the data interaction process CB may simultaneously start a plurality of calling threads, and call different programs respectively.
Further, when the call thread is created, a corresponding call request identifier is obtained by the CB.
Further, the program PA is in a state of waiting for a result after issuing the call request.
Further, the CA wakes up the PA from the waiting state and delivers the second processing result after obtaining the second processing result.
The beneficial effects of the application are as follows: the remote calling program design among heterogeneous platform programs is simplified, timeout processing is timely carried out, and the program running efficiency is improved.
[ description of the drawings ]
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification, illustrate and together with the description serve to explain the application, if necessary:
FIG. 1 is a schematic diagram of the structure of a plurality of heterogeneous platforms of the present application.
[ detailed description ] of the application
The present application will now be described in detail with reference to the drawings and the specific embodiments thereof, wherein the exemplary embodiments and the description are for the purpose of illustrating the application only and are not to be construed as limiting the application.
Referring to fig. 1, there is shown a structure between a plurality of heterogeneous platforms according to the present application, which at least includes more than two platforms, and the platforms communicate with each other through a network, where the network may be the internet or a local area network.
Two platforms are shown in fig. 1: platform A and platform B, platform A running program PA and platform B running program PB, program PA requiring communication with program PB. Specifically, the communication refers to program PA calling program PB remotely, and then program PB returns the calling result to program PA.
In order to complete the communication, the application introduces a data interaction process CA and CB on the platform A and the platform B respectively, and the processes CA and CB help programs PA and PB complete the communication between the platforms. The program communication method of the present application is described in detail below.
(1) Program PA generates a call request comprising an identifier of platform B, an identifier and interface of program PB to be called, a call parameter, a call request identifier.
In order to distinguish each platform, a unique identifier needs to be set for each platform in advance, so that each program can identify the platform which specifically needs to communicate. The identifier of the program PB may be generally the name of the program PB itself, and when the program PB runs, it may provide one or more call interfaces to the outside, and when a call needs to be provided, corresponding parameters need to be known in advance by the program PA. The call request identifier is a unique identifier generated by the PA for identifying the call request.
Based on the above information, the program PA can generate a corresponding call request.
(2) And the program PA writes the call request into a call buffer area of the platform A.
The call buffer area is a storage area specially opened in the memory of the platform A and is used for placing call requests during program communication. The call buffer is divided into a plurality of segments in advance, each segment stores a call request, and when the program PA writes its call request into one of the segments, an identifier of the program PA is written at the same time, the identifier indicating that the segment is occupied by the program PA.
According to one embodiment of the present application, a circular queue may be formed between the segments, and each write call request is written into an empty segment at the tail of the queue. Of course, other organizations may be employed, and the application is not limited in this regard.
For data security, the call buffer is controlled by the system, and the empty segments can be written by each program, but each program is not allowed to read the data of each call request in the call buffer, and only the data interaction process is allowed to read.
(3) And the data interaction process CA reads and analyzes the call request from the call buffer area and acquires the related information of the call request.
Specifically, since there may be a plurality of call requests stored in the call buffer at the same time, the data interaction process CA needs to fetch the call requests from the call buffer in a predetermined order. Generally, the predetermined order is the order in which call requests are placed in the call buffer in time, i.e., first-in-first-out order. For example, the call buffer is organized in a circular queue, and the call request may be fetched from the head of the queue.
The related information of the call request acquired by the data interaction process CA comprises an identifier of a program PA to which the data interaction process CA belongs, an identifier of a platform B, an identifier and an interface of a program PB to be called, a call parameter and a call request identifier.
(4) The data interaction process CA formats the related information of the call request according to the related requirement of the platform B, and generates a new call request (hereinafter referred to as a second call request), wherein the second call request also comprises an identifier of the platform A.
Because different heterogeneous platforms have different requirements for data formats, call formats and the like, the CA needs to process the call request according to the requirements of platform B, and format a second call request that meets the requirements of platform B. In this way, the data interaction process can process format conversion between different platforms by itself, and the details of the upper layer program PA are shielded, so that a designer of the program PA does not need to care about conversion requirements between heterogeneous platforms, and programming is simplified.
(5) And the data interaction process CA sends the second call request to the platform B, and the platform B stores the received second call request into a receiving buffer area.
As described above, the identifier of the platform B is included in the call request, so the CA may learn that the call request needs to be sent to the platform B, and based on the address of the platform B stored in advance, the CA may send the second call request to the platform B. After the CA sends the second call request, the CA may clear the call buffer of the corresponding call request.
The receiving buffer area is a storage area opened up in the memory of the platform B and is used for storing the received call request. Similar to the call buffer, the receive buffer is also divided into a plurality of segments, each segment storing a received call request and may form a first-in-first-out circular queue. The receiving buffer can only be read by the data interaction process CB on platform B.
(6) The data interaction process CB reads the second call request from the receiving buffer area, creates a call thread, calls a corresponding interface of the program PB based on information in the second call request, and transmits the call parameters.
As described above, the second call request includes the program PB to be called, the interface, and the call parameter, so the CB may learn the call target of the second call request, thereby call the corresponding interface of the PB, and transfer the call parameter provided by the PA to the PB.
The data interaction process CB can simultaneously start a plurality of calling threads to call different programs respectively, so that parallel processing can be ensured, and the processing efficiency is improved.
(7) Program PB accepts the call based on the call parameter, generates a corresponding processing result, returns the processing result to the call thread, and the call thread stores the processing result and the corresponding call request identifier in the result buffer of platform B.
When the call thread is created, a corresponding call request identifier is obtained at the CB, so that the call request identifier can be used to identify the call request to which the processing result belongs.
The result buffer area is similar to the receiving buffer area, is a storage area opened up in the memory of the platform B and is used for storing the processing result, the result buffer area is also divided into a plurality of segments, each segment stores a processing result and a corresponding calling request identifier, and a first-in first-out circular queue can be formed.
The result buffer area can be written into the empty section by each program, but only the data interaction process is allowed to read so as to ensure the data security.
(8) The data interaction process CB reads the processing result and the calling request identifier from the result cache area, the data interaction process CB determines a platform A corresponding to the calling request according to the calling request identifier, the processing result is formatted according to the related requirement of the platform A, and a second processing result meeting the requirement of the platform A is generated, wherein the second processing result comprises the formatting result of the processing result and the calling request identifier.
Specifically, the CB may query according to the call request identifier to obtain a corresponding second call request, and further obtain a platform a identifier in the second call request, so that the CB may know that the processing result should be sent to the platform a, and may format the processing result into a second processing result according to the requirements of the platform a. In this way, the data interaction process CB shields details of remote call to the program PB, simplifying the program design.
(9) And the data interaction process CB sends the second processing result to the platform A, and the platform A stores the received second processing result into a result return buffer area.
Similar to the other types of buffers described above, the result return buffer is also a storage area opened up in the platform a memory for storing the processing results returned by other platforms, and the result return buffer is also divided into a plurality of segments, each of which stores a second processing result, and may also form a first-in-first-out circular queue. The result return buffer can only be read by the data interaction process CA.
(10) And the data interaction process CA reads the second processing result from the result return buffer area, and determines a program PA corresponding to the second processing result according to the calling request identifier in the second processing result.
When the data interaction process CA transmits the call request, the correspondence between the call request identifier and the program PA should be stored, so that the corresponding program PA can be determined based on the call request identifier.
(11) The data interaction process CA sends the second processing result to the program PA.
In a specific implementation, after the program PA issues a call request, the program PA may be in a state of waiting for a result, and after obtaining the second processing result, the CA wakes up the PA from the waiting state and transmits the second processing result.
The above process is a basic process of the program communication method of the present application, but in the practical application process, the program remote communication between different platforms faces time limitation. For example, when the PA remotely invokes the PB, the PB fails to return the processing result in time for various reasons, and the PA may not always wait. Also for example: some programs have limitations on the response time of the call, requiring the called program to return results within a defined time, and therefore even though PB returns processing results, it is possible to exceed PA definition time. These conditions can cause errors in the calling process.
Based on this, the present application introduces relevant time parameters on the basis of the basic procedure described above. Specifically, the call request generated by the PA further includes a defined time parameter T, where the defined time parameter T represents a maximum acceptable waiting time for the PA to make a remote call. At the same time, the system records the time T when the call request is written into the call buffer 0 。
When the data interaction process CA reads the call request in step 3 above, it can get T 0 And T, CA first calculates the remaining time T 1 =T 0 +T-T now Wherein T is now Is the current time. The T is 1 In fact represents that the PA is acceptableThe remaining time of the result.
The data interaction process CA calculates the minimum expected time T of the processing result min T, i.e min =T 2 +T 3 ,
Wherein T is 2 Is the journey time for data to travel back and forth between platform a and platform B, which the CA can acquire by timing the data transfer between the platform (e.g., by ping, or heartbeat data transfer). T (T) 3 Is a predefined minimum time for the presentation program PB to process the call, which may be obtained empirically or based on the time that the PB processed a similar call in the past (e.g., a minimum of n processing times in the past).
Data interaction process CA judges T 1 And T is min Is a size relationship of (a):
if T 1 <T min And the data interaction process CA directly returns a failure result to the program PA.
If T 1 ≥T min The data interaction process CA continues to execute the subsequent steps, and the CA starts a timer which starts to count from 0, and when the timer reaches T 1 And when the CA does not acquire the corresponding second processing result, the CA returns a timeout result to the program PA, and informs the program PA that the returned result is timeout.
Through the related processing process of the limited time parameter, the problem of overtime of remote call can be better solved, and the efficiency of program operation is improved.
The foregoing description is only of the preferred embodiments of the application, and all changes and modifications that come within the meaning and range of equivalency of the structures, features and principles of the application are therefore intended to be embraced therein.
Claims (10)
1. A method of program communication between heterogeneous platforms, comprising the steps of:
(1) Program PA running on platform A generates a call request, wherein the call request comprises an identifier of platform B, an identifier and interface of program PB, a call parameter and a call request identifier; program PB is the program to be called by program PA, and runs on platform B;
(2) The program PA writes the call request into a call buffer area of the platform A;
(3) The data interaction process CA running on the platform A reads and analyzes the call request from the call buffer area to acquire the related information of the call request;
(4) The data interaction process CA formats the related information of the call request according to the related requirements of the platform B to generate a second call request, wherein the second call request also comprises an identifier of the platform A;
(5) The data interaction process CA sends the second call request to the platform B, and the platform B stores the received second call request into a receiving buffer;
(6) The data interaction process CB running on the platform B reads the second call request from the receiving buffer area, creates a call thread, calls a corresponding interface of the program PB based on information in the second call request, and transmits the call parameter;
(7) The program PB receives calling based on the calling parameters, generates corresponding processing results, returns the processing results to the calling thread, and stores the processing results and corresponding calling request identifiers in a result cache area of the platform B;
(8) The data interaction process CB reads the processing result and the calling request identifier from the result cache area, the data interaction process CB determines a platform A corresponding to the calling request according to the calling request identifier, formats the processing result according to the related requirement of the platform A, and generates a second processing result meeting the requirement of the platform A, wherein the second processing result comprises the formatting result of the processing result and the calling request identifier;
(9) The data interaction process CB sends the second processing result to the platform A, and the platform A stores the received second processing result into a result return buffer area;
(10) The data interaction process CA reads the second processing result from the result return buffer area, and determines a program PA corresponding to the second processing result according to a calling request identifier in the second processing result;
(11) The data interaction process CA sends the second processing result to the program PA.
2. The method of claim 1, wherein the call request further includes a defined time parameter T, the defined time parameter T representing a maximum acceptable latency for remote calls by the PA, while the system records the time T at which the call request was written to the call buffer 0 ;
When the data interaction process CA reads the call request in step 3, the CA calculates the remaining time T 1 =T 0 +T-T now Wherein T is now Is the current time;
the data interaction process CA calculates the minimum expected time T of the processing result min T, i.e min =T 2 +T 3 The method comprises the steps of carrying out a first treatment on the surface of the Wherein T is 2 Is the journey time of data back and forth between platform A and platform B, T 3 Is a predefined minimum time for representing program PB to process the call;
data interaction process CA judges T 1 And T is min Is a size relationship of (a):
if T 1 <T min The data interaction process CA directly returns a failure result to the program PA;
if T 1 ≥T min The data interaction process CA continues to execute the subsequent steps, and the CA starts a timer which starts to count from 0, and when the timer reaches T 1 And when the CA does not acquire the corresponding second processing result, the CA returns a timeout result to the program PA, and informs the program PA that the returned result is timeout.
3. A method according to any of claims 1-2, characterized in that the call buffer is a specially opened memory area in the platform a memory, which call buffer is divided into a number of segments in advance, each segment storing a call request, and when the program PA writes its call request to one of the segments, an identifier of the program PA is written at the same time, which identifier indicates that the segment is already occupied by the program PA.
4. A method according to claim 3, characterized in that the call buffer is controlled by the system, allowing each program to write to an empty segment, but not allowing each program to read the data of each call request in the call buffer, only allowing the data interaction process CA to read the call request data.
5. The method of any of claims 1-4, wherein after the CA sends the second call request, the CA clears the corresponding call request in the call cache.
6. The method according to any of claims 1-5, wherein the receiving buffer is a storage area opened up in the memory of platform B for storing the received call requests, the receiving buffer is divided into a plurality of segments, each segment storing a received call request, the receiving buffer being readable only by the data interaction process CB on platform B.
7. The method according to claim 1, wherein the data interaction process CB can simultaneously start a plurality of calling threads, and call different programs respectively.
8. The method of claim 1, wherein the call thread is created with a corresponding call request identifier obtained at the CB.
9. The method of claim 1, wherein the program PA is in a state waiting for a result after issuing the call request.
10. The method of claim 9, wherein the CA wakes up the PA from a wait state and delivers the second processing result after obtaining the second processing result.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910617450.8A CN112199205B (en) | 2019-07-08 | 2019-07-08 | Program communication method between heterogeneous platforms |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910617450.8A CN112199205B (en) | 2019-07-08 | 2019-07-08 | Program communication method between heterogeneous platforms |
Publications (2)
Publication Number | Publication Date |
---|---|
CN112199205A CN112199205A (en) | 2021-01-08 |
CN112199205B true CN112199205B (en) | 2023-10-27 |
Family
ID=74004716
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910617450.8A Active CN112199205B (en) | 2019-07-08 | 2019-07-08 | Program communication method between heterogeneous platforms |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112199205B (en) |
Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5265250A (en) * | 1990-03-29 | 1993-11-23 | At&T Bell Laboratories | Apparatus and methods for performing an application-defined operation on data as part of a system-defined operation on the data |
US6594689B1 (en) * | 1997-05-08 | 2003-07-15 | Unisys Corporation | Multi-platform helper utilities |
CN1811717A (en) * | 2006-01-10 | 2006-08-02 | 杭州东信灵通电子实业公司 | Universal interprocess communication achieving method |
CN104133674A (en) * | 2014-07-11 | 2014-11-05 | 国家电网公司 | Heterogeneous system and model synchronization method of heterogeneous system |
CN105357266A (en) * | 2015-09-30 | 2016-02-24 | 山东乾云启创信息科技股份有限公司 | Universal SOCKET communication and process management platform applied to multiple scenes and method |
CN105357273A (en) * | 2015-09-30 | 2016-02-24 | 山东乾云启创信息科技股份有限公司 | Universal SOCKET communication and process management platform and method in asynchronous communication mode |
CN106357591A (en) * | 2015-07-16 | 2017-01-25 | 中兴通讯股份有限公司 | Inter-application data access method and device |
CN107153583A (en) * | 2017-05-24 | 2017-09-12 | 努比亚技术有限公司 | A kind of striding course interaction processing method, mobile terminal and computer-readable recording medium |
CN107491355A (en) * | 2017-08-17 | 2017-12-19 | 山东浪潮商用系统有限公司 | Funcall method and device between a kind of process based on shared drive |
CN108228359A (en) * | 2016-12-15 | 2018-06-29 | 北京京东尚科信息技术有限公司 | Web programs integrate the method and system of processing data with R programs |
CN108984317A (en) * | 2018-06-21 | 2018-12-11 | 北京奇虎科技有限公司 | The implementation method and device of interprocess communication IPC |
CN109189584A (en) * | 2018-07-05 | 2019-01-11 | 北京三快在线科技有限公司 | Communication means, device, electronic equipment and storage medium between application program |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20180232403A1 (en) * | 2017-02-15 | 2018-08-16 | Ca, Inc. | Exposing databases via application program interfaces |
-
2019
- 2019-07-08 CN CN201910617450.8A patent/CN112199205B/en active Active
Patent Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5265250A (en) * | 1990-03-29 | 1993-11-23 | At&T Bell Laboratories | Apparatus and methods for performing an application-defined operation on data as part of a system-defined operation on the data |
US6594689B1 (en) * | 1997-05-08 | 2003-07-15 | Unisys Corporation | Multi-platform helper utilities |
CN1811717A (en) * | 2006-01-10 | 2006-08-02 | 杭州东信灵通电子实业公司 | Universal interprocess communication achieving method |
CN104133674A (en) * | 2014-07-11 | 2014-11-05 | 国家电网公司 | Heterogeneous system and model synchronization method of heterogeneous system |
CN106357591A (en) * | 2015-07-16 | 2017-01-25 | 中兴通讯股份有限公司 | Inter-application data access method and device |
CN105357266A (en) * | 2015-09-30 | 2016-02-24 | 山东乾云启创信息科技股份有限公司 | Universal SOCKET communication and process management platform applied to multiple scenes and method |
CN105357273A (en) * | 2015-09-30 | 2016-02-24 | 山东乾云启创信息科技股份有限公司 | Universal SOCKET communication and process management platform and method in asynchronous communication mode |
CN108228359A (en) * | 2016-12-15 | 2018-06-29 | 北京京东尚科信息技术有限公司 | Web programs integrate the method and system of processing data with R programs |
CN107153583A (en) * | 2017-05-24 | 2017-09-12 | 努比亚技术有限公司 | A kind of striding course interaction processing method, mobile terminal and computer-readable recording medium |
CN107491355A (en) * | 2017-08-17 | 2017-12-19 | 山东浪潮商用系统有限公司 | Funcall method and device between a kind of process based on shared drive |
CN108984317A (en) * | 2018-06-21 | 2018-12-11 | 北京奇虎科技有限公司 | The implementation method and device of interprocess communication IPC |
CN109189584A (en) * | 2018-07-05 | 2019-01-11 | 北京三快在线科技有限公司 | Communication means, device, electronic equipment and storage medium between application program |
Non-Patent Citations (3)
Title |
---|
Analytical Communication Performance Models as a metric in the partitioning of data‑parallel kernels on heterogeneous platforms;Juan A. Rico‑Gallego等;《The Journal of Supercomputing》;全文 * |
Streaming Applications on Heterogeneous Platforms;Zhaokui Li 等;《arXiv》;全文 * |
异构系统间通信服务机制研究;张峻崎;《网络与通信》;全文 * |
Also Published As
Publication number | Publication date |
---|---|
CN112199205A (en) | 2021-01-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN112379995B (en) | DAG-based unitized distributed scheduling system and method | |
CN102591964B (en) | Implementation method and device for data reading-writing splitting system | |
US8112559B2 (en) | Increasing available FIFO space to prevent messaging queue deadlocks in a DMA environment | |
CN110677462B (en) | Access processing method, system, device and storage medium for multi-block chain network | |
CN102063338B (en) | Method and device for requesting exclusive resource | |
CN110647511A (en) | Data synchronization method, computing device and computer storage medium | |
JPH05207025A (en) | System and method for acquisition of netwrok performance data | |
CN111857993B (en) | Method for calling user mode function in kernel mode | |
CN107562685B (en) | Method for data interaction between multi-core processor cores based on delay compensation | |
CN109756461A (en) | A kind of remote procedure calling (PRC) method based on NETTY | |
CN102323894A (en) | System and method for realizing non-blockage mutual calling in distributed application of enterprise | |
US9069592B2 (en) | Generic transport layer mechanism for firmware communication | |
CN113157411B (en) | Celery-based reliable configurable task system and device | |
US8631086B2 (en) | Preventing messaging queue deadlocks in a DMA environment | |
CN109086119A (en) | A kind of method of quick detection container operating status | |
CN113946445A (en) | Multithreading module based on ASIC and multithreading control method | |
CN113127139B (en) | Memory allocation method and device based on DPDK of data plane development kit | |
CN112114983B (en) | Communication method, device and equipment based on shared memory | |
CN112199205B (en) | Program communication method between heterogeneous platforms | |
CN102902593A (en) | Protocol distribution processing system based on cache mechanism | |
US20230393782A1 (en) | Io request pipeline processing device, method and system, and storage medium | |
CN108255515A (en) | A kind of method and apparatus for realizing timer service | |
CN107102901B (en) | Task processing method and device | |
CN101634956A (en) | Dispatching method and dispatcher of information of polynuclear processor | |
CN103399949B (en) | A kind of database storage block state control method and device |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |