RU2574815C2 - Method of providing communication in communication environment, computer system and nonvolatile computer-readable data medium - Google Patents

Abstract

FIELD: radio engineering, communication.

SUBSTANCE: invention relates to communication in a communication environment. Disclosed is a method of providing communication in a communication environment, which includes: receiving, by a communication environment processor from a communication environment sender, a preliminary permit to convert a synchronous data transfer into an asynchronous data transfer, wherein the preliminary permit includes obtaining a memory unit indication to monitor asynchronous data transfer; receiving, by the processor from the sender, a request to transmit data to a communication environment user; initiating, by the processor, data transmission to a recipient, performed using synchronous data transfer; establishing, by the processor, the need to convert synchronous data transfer into asynchronous data transfer; and, performed upon said establishment, automatic conversion, by the processor, of synchronous data transfer into asynchronous data transfer to complete data transmission to the recipient, wherein the automatic conversion is independent of any actions of the sender, except the preliminary permit.

EFFECT: high efficiency of transmitting data in a communication environment.

31 cl, 15 dwg

Description

According to one of its features, the present invention relates generally to maintaining communication in a communication medium, more specifically, to facilitating the exchange of data between isolated memory areas of a communication medium.

For the exchange of data between isolated memory areas of a communication medium, network hardware and protocols are typically used. In particular, data can be transferred from one isolated memory area to another isolated memory area using the Transmission Control Protocol / IP protocol (TCP / IP) over an Ethernet network channel. Existing network technology allows you to transfer data synchronously or asynchronously. The selection is made solely by the sender.

With synchronous data transfer, the sender's work is suspended until the data transfer is completed. On the other hand, when sending data asynchronously, the sender can continue to act.

Overcoming the drawbacks of the prior art and achieving advantages is provided in a method for providing communication in a communication medium, including: obtaining, by the processor of the communication medium from the sender of the communication medium, prior permission to convert the synchronous data transfer to the asynchronous data transfer, the preliminary permission including receiving an indication of the memory unit for asynchronous data transfer; receipt by the processor from the sender of a request for data transmission to the recipient of a communication medium; initiation by the processor of data transmission to the recipient using synchronous data transfer; the establishment by the processor of the need to convert synchronous data transfer to asynchronous data transfer; and the automatic conversion performed by the processor for synchronously transferring data to asynchronous data transfer to complete the data transfer to the recipient, with the automatic conversion being independent of any actions of the sender, except for prior permission.

Objects of the invention are also a computer system configured to implement the method described above, as well as a non-volatile computer-readable storage medium that stores instructions read and executed by a data processing device for implementing the method described above.

The technical result achieved by the implementation of the invention is to facilitate the transfer of data in a communication environment by indicating a memory unit for tracking asynchronous data transfer, which, in particular, allows the sender to adjust the maximum number of outstanding asynchronous transfer requests and automates asynchronous data transfer.

Additional features and advantages of the invention are realized by the methods disclosed in the described embodiments. The description describes in detail other embodiments and features that are considered part of the claimed invention.

One or more features of the present invention are specifically characterized and separately claimed in the claims following the description. The above and other objectives, features and advantages of the invention will become apparent from the following further detailed description in combination with the accompanying drawings, in which:

in FIG. 1 illustrates one example of a communication medium in which one or more features of the present invention are contained and / or used,

in FIG. 2 illustrates examples of memory areas associated with those illustrated in FIG. 1 logical partitions according to one of the features of the present invention,

in FIG. 3 is one example of an outgoing synchronous data transfer used according to one aspect of the present invention,

in FIG. 4 illustrates examples of control structures used to automatically convert a synchronous data transfer to an asynchronous data transfer, according to one aspect of the present invention,

in FIG. 5A is an embodiment of a logic for automatically converting synchronous data transfer to asynchronous data transfer according to one aspect of the present invention;

in FIG. 5B is one illustrative example of the successful completion of asynchronous data transfer according to one of the features of the present invention;

in FIG. 6 is one embodiment of a computer program product that contains one or more features of the present invention,

in FIG. 7 is one embodiment of a host computer system that contains and uses one or more features of the present invention,

in FIG. 8 is an additional example of a computer system that contains and uses one or more features of the present invention,

in FIG. 9 is another example of a computer system comprising a computer network in which one or more features of the present invention are contained and used,

in FIG. 10 is one embodiment of various elements of a computer system in which one or more features of the present invention are contained and used,

in FIG. 11A is one embodiment of a block of execution illustrated in FIG. 10 of a computer system in which one or more features of the present invention are contained and used,

in FIG. 11B is one embodiment of a transition instruction execution unit illustrated in FIG. 10 of a computer system in which one or more features of the present invention are contained and used,

in FIG. 11B is one embodiment of a block for executing load / save instructions illustrated in FIG. 10 a computer system that contains and uses one or more features of the present invention, and

in FIG. 12 is one embodiment of a host computer emulation system that contains and uses one or more features of the present invention.

According to one aspect of the present invention, there is provided a means for automatically converting synchronous data transfer to asynchronous data transfer. For example, synchronous data transfer is automatically converted to asynchronous data transfer if it is determined that the completion of data transfer is delayed, for example, the data recipient is not able to receive data during the transfer. Converting synchronous data transfer to asynchronous data transfer is automatic in the sense that it is not performed at the request of the sender (or recipient), and the sender (or recipient) is not aware of the conversion at the time of its initiation. In addition, at the time of conversion, the sender (or recipient) is not required to take any action or interfere with the conversion.

One embodiment of a communication medium in which one or more features of the present invention is contained and / or used is described with reference to FIG. In one example, communications environment 100 comprises a central processing unit (CPC) complex 102, which is based on the z / Architecture ^{® system} offered by International Business Machines Corporation (IBM ^® ). The features of the z / Architecture ^{® system are} described in publication No. SA 22-7832-08 "IBM ^® z / Architecture Principles of Operation" (August 2010), which is hereby incorporated by reference in its entirety. One of the systems that can contain a complex of 102 central processors is the zEnterprise 196 (z196) system, offered by International Business Machines Corporation (Armonk, New York, USA). IBM ^® and z / Architecture ^® are registered trademarks, and zEnterprise 196 and z196 are trademarks of International Business Machines Corporation (Armonk, New York, USA). Other product names used in the description may be registered trademarks, trademarks or product names of International Business Machines Corporation or other companies.

The complex 102 of the Central processors contains, for example, one or more partitions 104, a hypervisor 106, one or more central processors 108 and one or more components of the I / O subsystem 110. In this example, one or more partitions 104 are logical partitions (also known as LPARs) that contain a set of system hardware resources in the form of a separate virtual system.

Each logical partition 104 is able to function as a separate system. In other words, each logical partition can independently return to its original state, if desired, it can bootstrap the operating system 120, and it can operate with various programs. An operating system or application running in a logical partition looks like it has access to the entire system as a whole, but, in reality, only part of it is available to it. By combining hardware and licensed internal code (LIC), also called hardware-software, the mutual influence of a program in one logical partition and a program in another logical partition is prevented. This allows several different logical partitions to use one or many physical processors in a time slicing mode. In this example, several logical partitions have a resident operating system 120, which may vary in one or more logical partitions. In one embodiment, operating system 120 is the operating system z / OS ^®, offered by International Business Machines Corporation (Armonk, NY, USA).

In the context of the present invention, the firmware contains, for example, microcode, millicode and / or macrocode of the processor. It contains, for example, hardware-level instructions and / or data structures used in the implementation of high-level machine code. In one embodiment, it comprises, for example, native code, which is typically microcode containing verified software or specific to the underlying hardware and controlling the access of the operating system to the system hardware.

The logical partitions 104 are controlled by a hypervisor 106, which is implemented through hardware and software running on central processors 108. One example of a hypervisor 106 is the Processor Resource / Systems Manager (PR / SM ™), offered by International Business Machines Corporation (Armonk, New York, USA).

Central processors 108 are the physical resources of a processor that are allocated to logical partitions. For example, a logical partition 104 contains one or more logical processors, each of which displays all or part of the physical resources 108 of the processor allocated to the partition. The logical processors of a particular partition 104 may be assigned to a partition, in which case the core processor resources are reserved for that partition; or can be used in conjunction with another partition, in which case the core processor resources are potentially available for another partition.

The logical partitions 104 and the hypervisor 106 in each case may contain one or more programs permanently stored in the corresponding parts of the main memory 150 associated with the central processors. In one example, each logical partition is allocated a portion of main memory, referred to as a memory region, as described in more detail below with reference to FIG.

As shown in FIG. 2, in one embodiment, the main memory 150 comprises a plurality of memory areas, each of which has a range of addresses in the main memory. A memory area can be allocated to any object, such as a logical partition, or to another object. In the example illustrated in FIG. 2, two memory areas are allocated, respectively, to two logical partitions. One memory region is referred to as the sender's memory region 202, and another memory region is referred to as the recipient's memory region 204, since the relationship between the sender and the receiver is further described. The sender’s memory region 202 contains, for example, one or more input queues 210, one or more output queues 212, and one or more buffers 214. Similarly, in the recipient’s memory region 204, one or more input queues 220, one or more output queues 222 and one or more buffers 224. The use of queues and buffers is further described below.

Separate memory areas are isolated from each other in the sense that data cannot be written directly from one memory area to another memory area without control by hardware and software. In one example, network transfer using, for example, TCP / IP over Ethernet channels, is used to transfer data from one memory area to another memory area. In one specific example, a technology called HiperSockets ™ is proposed by the International Business Machines Corporation for forwarding.

HiperSockets ™ provides the ability to establish high-speed TCP / IP communications in a complex of central processors. This eliminates the need for any physical cable network or external network connections between servers operating in different logical partitions. Instead, communication is via the processor system memory. HiperSockets ™ is based on the OSA-Express Direct Queued Queuing (QDIO) protocol. The firmware emulates the OSA-Express QDIO interface channel control layer.

Forwarding data from one memory area to another memory area using network technology is, for example, synchronous, and in this case, after the initiation of data transfer, the sender's work is suspended until the transfer is completed. One example of the synchronous transfer of data from one memory area to another is described with reference to FIG. 3.

As shown in FIG. 3, a sender 300, such as a TCP / IP protocol stack or a program operating in the memory area of the sender, initiates a data transfer request to a recipient 310, such as another TCP / IP protocol stack or program, such as a receiver memory . Since in this example the recipient’s memory area is isolated from the sender’s memory area, the network communication protocol is used to synchronously transfer data from the sender to the receiver. The use of synchronous data transfer provides a high-speed direct communication channel with a low latency between the sender and receiver by transferring data from one memory area to another under the control of hardware and software. In one example, data is transferred from one memory area to another using HiperSockets ™. This forwarding mechanism is very efficient because the receiver can receive data at the same or higher speed than the sender's data rate.

To forward data, the sender retrieves the data that is contained in the selected data buffer 320 and places it in the sender's output queue 330 (OUTQ). For example, a pointer 332 of the selected data buffer is placed in the output queue. Then, the sender 300 transmits to the processor a signal 340 for sending data to the recipient 310. In one example, the signal is transmitted to the hardware and software of the processor 350, which is about to transfer; however, in other examples, the signal is transmitted not to the firmware, but to another code and / or hardware of the processor.

In response to receiving a signal requesting data to be sent from the sender to the recipient, the hardware and software copies the data from the sender's output queue and places it in the receiver's 360 input queue (INQ). For example, the data is copied to an empty buffer 370, and the pointer 372 of this data is placed in the input queue 360. After the data transfer is complete, the firmware transmits the transfer completion signal to the sender. Until the sender receives this completion signal, its operation is suspended and it cannot perform any other operations.

As one of the specific examples, in order to transmit a signal to the processor, the sender transmits a signal adapter command (SIGA, from English - Signal Adapter) indicating the recording function (SIGA-w), which tells the processor that one or more output queues contains data to be transmitted to the recipient. The recording function is defined as a function code contained in the first general general register used by the command, and the second general purpose register used by the command indicates the network connection address (for example, subsystem identifier) of the recording function. In addition, in another, third general purpose register used by the command, output queues are defined.

In this particular example, the queues are implemented as direct access queues with queuing (QDIO), with each queue having many buffers associated with it, as well as various control information. In one embodiment, the QDIO queue comprises data structures describing the queue, as well as blocks of buffer storage devices that are used to transfer data. As one example, data structures of a plurality of storage devices, called queue components, which collectively describe the characteristics of a queue and provide control tools for exchanging data, include, for example:

a queue information block (QIB), which contains information about the totality of the input and output QDIO queues. The QIB contains the address of the storage unit information block list (SLIB) for input queues and the SLIB address for output queues.

There is one SLIB for each queue, and each SLIB contains information about the queue and about each queue buffer. Each SLIB has a header and one or more elements, called elements of a block of information from the list of storage devices (SLIBE), which contain information about each of the queue buffers. In one example, each block of information from the list of storage devices contains the address of the next block of information from the list of storage devices, the address of the list of storage devices (SL), and the address of the status block of the list of storage devices (SLSB).

For each queue, one list of storage devices is defined, which contains, for example, 128 entries, one for each of the queue buffers. The list of storage devices contains information about the locations of the I / O buffers in the main memory. Each record contains the absolute address of the list of addresses of blocks of storage devices (SBAL). Each list of addresses of blocks of storage devices contains a list of absolute addresses of blocks of storage devices, which together form one of the data buffers associated with each queue.

Each SBAL includes an entry from the list of memory blocks (SBALE). Each SBALE contains the absolute address of the storage unit. Collectively, the blocks of storage devices addressed by all records of a single SBAL form one of the many possible QDIO buffers of the QDIO queue. In one example, a QDIO queue may contain 128 associated QDIO buffers.

The SLSB contains status indicators that provide information about the status of the buffers that make up the queue.

Further details regarding SIGA, QDIO queues, and associated control structures are described in US Pat. No. 6,332,171 B1 entitled "Self-Contained Queues With Associated Control Information For Receipt And Transfer Of Incoming And Outgoing Data Using A Queued Direct Input-Output Device" in the name Baskey et al., Issued December 18, 2001; US patent 6345241 B1 entitled "Method And Apparatus For Simulation Of Data In a Virtual Environment Using A Queued Direct Input-Output Device" in the name of Brice et al., issued February 5, 2002; US 6,519,645 B2, entitled "Method And Apparatus For Providing Configuration Information Using A Queued Direct Input-Output Device" to Markos et al., issued February 11, 2003; and U.S. Pat. No. 7,941,799 B2 entitled "Interpreting I / O Operation Requests From Pageable Guests Without Host Intervention" to Easton et al., issued May 10, 2011.

When the receiver is not able to use empty buffers at the same speed as the sender transmits data during the described processing, on the sender side the waiting time and CPU resources are increased due to the synchronous nature of the protocol. When an empty buffer is not available to the recipient, the sender has two options. It can take the cost of resources to queue the failed operation and then retransmit the data to the same recipient, or discard the data so that a higher-level communication protocol such as TCP / IP can trigger the operation again. The difficulty with queuing and retransmission of data lies in the fact that this not only requires the restoration of additional CPU cycles, but the subsequent transfer of data by the sender to other destinations that may be able to receive incoming data can potentially be blocked or delayed.

In virtual environments in which multiple servers (for example, senders, recipients) can share CPU resources, it is more likely that situations arise in which the recipient may not be able to maintain the speed at which different senders transmit data to him. This usually happens when a hypervisor such as PR / SM manages server scheduling in the various shared processors available. The problem is solved when there are hypervisors of many levels between the sender and the shared CPU resource. This is the case, for example, when the sender acts in a virtual machine running z / VM ^® , which also acts in a logical partition. In this case, two hypervisors must dispatch the server in such a way that it promptly replenishes empty buffers.

Timely scheduling of the recipient does not create difficulties if there are sufficient available CPU resources. Synchronous data transfer is interrupted only when the CPU resources are limited for a short or long time. So, according to one of the features of the present invention, the sender is able to use synchronous data transmission with low latency in the environment without limiting CPU resources while eliminating the associated difficulties and costs when CPU resources become limited. This is achieved by converting the synchronous exchange protocol into an asynchronous exchange protocol, when the receiver is not able to maintain the data rate of the sender. In one embodiment, the synchronous exchange protocol is automatically converted to the asynchronous exchange protocol without any notification to the sender (i.e., the sender does not need to perform any action at the time of conversion). Thus, the sender is freed from the need to perform some type of recovery or to block or slow down data transfer to other recipients when CPU resources become limited for a particular recipient. In addition, synchronous data transfer to a recipient with previously limited resources may resume automatically.

According to one aspect of the present invention, there is provided a means of organizing a data queue in a memory by a sender until a receiver provides empty buffers that can receive data. In order to facilitate this, one or more of the control structures described with reference to FIG. 4 is used. For example, the sender allocates an empty block 400 in its each incomplete asynchronous transfer. In one example, the number of these blocks at any given time can be X, with X being a model dependent and configurable quantity. X displays the number of simultaneous asynchronous forwarding requests allowed by the sender. This memory block, called the QDIO (Direct I / O Queuing) (QAOB), is used to monitor asynchronous data transfers until the firmware completes the operation. In this example, the QAOB contains only control information, not the data itself. The sender uses this block when initiating the transfer of data for requests that he does not necessarily allow asynchronous execution; otherwise, it does not need to provide a control unit. This allows the sender to adjust the maximum number of failed asynchronous forwarding requests. The QAOB as such is used and initialized only by the firmware when it determines that the data transfer should be asynchronous. No action is required from the sender to transfer data other than providing memory for the QAOB if the transfer of data should be asynchronous.

In one specific example, QAOB is included in the SIGA command that contains the request. The sender transmits a SIGA write command with QAOB (SIGA-wq) indicating the selected function code in the first general register in which the write function with QAOB is indicated. The fourth general-purpose register used by the command indicates the QAOB address. This general-purpose register is set to 0 when no QAOB is specified, or contains an absolute QAOB address (for example, a 256-byte QAOB). In response to the specified code, the QAOB recording function determines whether the QAOB is specified in the fourth general purpose register, which can be used for asynchronous data transfer.

When the firmware changes the data transfer protocol to asynchronous, it uses the QAOB to monitor data permanently stored in the sender's memory associated with the transfer of outgoing data. In an example in which HiperSockets ™ are used for transmission, the QAOB monitors the addresses and controls indicated by the sender in the SBAL list associated with the data transfer. Examples of fields retrieved from SBAL and placed in a QAOB include, for example:

all significant SBALEs from SBAL (for example, the first SBALE for SBALE with the last bit set). They contain the absolute address of the data buffer and the byte count;

SBAL output queue number,

buffer number (e.g. 1-27) of the SBAL initiating the request,

the number of significant SBALE entries and

a storage key used to access the storage units indicated by each significant SBALE.

In addition to QAOB, another control structure is used, referred to as completion queue 410 (CQ). In other words, in one example, in addition to providing QAOB, the sender also selects a new type of queue in its memory, namely, the completion queue when forming the queue of transmitted data. In the case of HiperSockets ™, it is the QDIO input queue with SBAL, but without the buffers associated with SBALE. This new input queue is not used to send data, but is used by the hardware and software to report completion events to notify the sender of the completion of asynchronous data transfer. When a queue entry is marked as "incoming", the completion event information is in the SBALEs themselves, which are included in the completion queue. The firmware reports the QAOB address associated with the completed asynchronous data transfer to CQ, and generates an interrupt if necessary to notify the sender of the completed data transfer. At this point, the sender can reuse for other purposes the memory associated with the completed operation. (In one embodiment, SBALE is used to report one completion event. Since SBAL contains, for example, 16 SBALEs, the firmware can report up to 16 completion events (QAOBs) in one SBAL.)

In addition, in one embodiment, the firmware generates another TPQ 420 queue for the intended recipient, which is used to remember that there is an outstanding data transfer request.

Further details of converting synchronous data transfer to asynchronous data transfer are described with reference to FIGS. 5A-5B. FIG. 5A illustrates one embodiment of the logic used by the firmware to perform the conversion, and FIG. 5B illustrates one example of the conversion. Both figures are discussed further in the description.

As shown in FIGS. 5A-5B, first in step 500, the firmware 350 receives the QAOB indication (for example, the address of a storage unit that can be used to transfer data asynchronously). Accordingly, he knows that if necessary (or if desired), it can asynchronously perform the requested data transfer. In one embodiment, the firmware may receive multiple QAOBs indicating that it can execute up to a specified number of asynchronous data transfers. Providing the QAOB by the sender is a preliminary permission for the hardware and software to perform asynchronous data transfer, if selected by the hardware and software.

In one specific example, the QAOB is included in the data transfer request, which the firmware receives at step 502 from the sender 300. In response to receiving the data transfer request at step 504, the firmware tries to transfer data to the recipient. If it is determined in step 506 of the request that the recipient is able to receive data (for example, the recipient has an empty buffer), the data is synchronously transferred in step 508, and the data transfer is completed. After that, the sender can perform another data transfer, and if the sender allows asynchronous processing, it can include QAOB in a new request.

Nevertheless, if the receiver is not able to receive data at the moment (for example, as determined by the state of the buffers, the receiver does not have an empty buffer, and, accordingly, the receiver does not receive data), the data transfer request is automatically converted by the firmware from synchronous to asynchronous provided that the request contains a QAOB. The request is stored in the QAOB at step 510, and the QAOB is placed in the TPQ 420 queue of the planned destination, for example, by placing the QAOB pointer in the TPQ in step 512. Now the contents of SBAL are included in the QAOB, and, accordingly, SBAL can be used for other processing.

In one embodiment, if no QAOB is specified, the request is not executed or is waiting for synchronous transmission.

In one example, in response to queuing a QAOB, control is transferred to the sending server indicating that the specified QAOB is used for this asynchronous data transfer. Then, the sending server can immediately tune in to its next data transfer, and it is not necessary to allocate another QAOB if it is necessary for the next data transfer.

Then, in step 514 of the request, it is determined whether the recipient is able to receive data. For example, it is determined whether the firmware received a signal from the receiver indicating that the receiver is currently able to receive data (for example, there are empty buffers available), or whether the firmware has established that a buffer is available by checking the status of the buffers. In one specific example, the receiver uses the SIGA command to send a signal to the firmware indicating that the receiver has placed empty buffers in its input queues. The first general-purpose register contains the SIGA Read Function Code (SIGA-r). The SIGA read function encourages the firmware to forward any pending packets from the receiver's TPQ queue to the input buffers of the target.

If the recipient is not able to receive the data, the firmware goes to wait. Otherwise, if the receiver is capable of receiving data (for example, there is at least one empty buffer), the firmware determines in step 518 whether it has a QAOB pointer in the receiver's TPQ queue. If this is not the case, processing ends. Otherwise, the firmware uses QAOB to send data. In particular, it sends the data specified by QAOB to the recipient, placing the data in an empty buffer and placing the pointer of the now full buffer in the input queue of the recipient.

After that, the firmware in step 520 indicates to the sender that the data transfer has been completed. In one example, this indication reports the QAOB address associated with the completed asynchronous data transfer in the completion queue 410 (FIG. 5B) of the sender, and an interrupt 550 is generated if necessary to inform the sender of the completed data transfer. At this point, the sender can reuse for other purposes the memory associated with the completed operation. The QAOB indicated in the CQ contains information regarding asynchronous processing, including, for example, status information, termination codes, error codes, etc.

In one specific example, when the QAOB address is specified in the receipt in the completion queue (i.e., the QAOB address is included in SBALE in one of the entries in the completion queue), the firmware returns the following information to the QAOB program, for example:

a reason code that reflects the results of an asynchronous I / O operation,

Buffer status: "Queue - Buffer Status N (SQBN)" for asynchronous data transfer. It has the same value that would be placed in the SLSB for synchronous data transfer. SQBN contains a value indicating the current state of the QAOB. The value of the state variable contains, for example, two parts: the first part indicates whether the buffer belongs to the hardware and software, and the second part indicates the current state of the QAOB process.

Although a particular request is executed asynchronously, other sender requests addressed to other recipients can be executed synchronously, unless, for example, the reception of data by a specific recipient is delayed. In addition, other requests addressed to the receiver by the sender are automatically converted to synchronous, unless it is again established that the reception of data by the receiver is delayed. For example, the firmware attempts to transfer data to the recipient as described above, and if the recipient is able to receive data, they are transmitted synchronously. In one embodiment, even when the synchronous and asynchronous transmission are mutually converted, the data is processed in the order of receipt as in the transmission. The firmware transfers all pending QAOB services to the recipient's TPQ 420 queue before receiving any future synchronous requests from this or any other sender. If you try another synchronous transfer of data to a recipient whose QAOB has already been placed in its TPQ 420, it will be automatically converted to an asynchronous request by the hardware-software (if allowed by the sender) or it will fail, and the answer will be "no available buffers". Preserving order avoids costly processing for reordering, improves the efficiency of the receiver's TCP / IP protocol stack, and overall CPU utilization.

The means for automatically converting synchronous data transfer to asynchronous data transfer in response to a processor (for example, hardware and software) that such a conversion should occur have been described in detail above. For example, the conversion is carried out if the data reception by the receiver is delayed (for example, due to the lack of an available buffer, slow response, etc.). In addition, the tool automatically allows you to synchronously perform other data transfers to the same recipient.

One or more of the features of this tool allows you to configure for transit or longer-term data transmission without costly retransmissions while maintaining communication with the target destination and with minimal or no effect on other existing destinations in the network. According to one of the features, a means of switching between synchronous and asynchronous data transfer without notifying the sending program is proposed. In one specific example using the HiperSockets-based completion queue (CQ), the device driver does not suspend the I / O operation (SIGA does not block the process). When using CQ, the recording process is not interrupted, and the sender can continue to transmit additional write commands (SIGA) to the same destination or other destinations, while some of them can be executed synchronously and others asynchronously. This lack of blocking makes CQ asynchronous.

According to one aspect of the present invention, data is only copied once from the sender to the recipient (without an internal buffer), regardless of whether the transfer is synchronous or asynchronous.

As those skilled in the art will appreciate, one or more of the features of the present invention may be embodied as a system, method, or computer program product. Accordingly, one or more features of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (comprising hardware and software, resident software, microcode, etc.) or an embodiment combining software and hardware features that are all may generally be referred to in the description as a “circuit”, “module” or “system”. In addition, one or more features of the present invention may take the form of a computer program product embodied in one or more computer-readable environments in which computer-readable program code is recorded.

Any combination of one or more permanent computer readable media may be used. The computer-readable medium may be a computer-readable storage medium. A computer-readable storage medium may be, for example, without limitation, an electronic, magnetic, optical, electromagnetic, infrared or semiconductor system, device or device, or any applicable combination of the above. More specific examples (non-exhaustive list) of a machine-readable storage medium include: an electrical connection containing one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable read-only memory device on compact disc (CD-ROM), optical storage device, magnetic storage device Do any applicable combination of these. In the context of this document, a computer-readable storage medium may be any material medium in which a program may be contained or stored for use by, or with reference to, a command execution system, device or device.

As shown in FIG. 6, in one example, a computer program product 600 includes, for example, one or more permanent computer-readable storage media 602 for storing computer-readable program code or logic 604 therein to provide and implement one or more aspects of the present invention.

The program code embodied in a machine-readable medium may be transmitted using an appropriate medium, including, without limitation, a wireless, wired medium, fiber optic cable, RF environment, etc. or any applicable combination of the above.

Computer program code for performing operations providing features of the present invention can be written in one or more programming languages in any combination, including an object-oriented programming language such as Java, Smalltalk, C ++, etc., and traditional procedural programming languages such as "C" and assembly languages or similar programming languages. The program code may be entirely executed on a user computer, partially on a user computer, as a stand-alone software package, partially on a user computer and partially on a remote computer or entirely on a remote computer or server. In the case of the latter scenario, the remote computer can be connected to the user computer via any type of network, including a local area network (LAN) or wide area network (WAN), or it can be connected to an external computer (for example, over the Internet using a service provider The Internet).

Features of the present invention are described with reference to block diagrams and / or block diagrams of methods, equipment (systems), and computer program products according to embodiments of the invention. It is understood that each block in the structural diagrams and / or block diagrams and combinations of blocks in the structural diagrams and / or block diagrams can be implemented by computer program control commands. These computer program control commands may be transmitted to a universal computer processor, specialized computer, or other programmable data processing device in order to form a mechanism in which instructions executed by a computer processor or other programmable data processing equipment provide a means for implementing functions / actions indicated by a block or blocks in structural diagrams and / or block diagrams.

These computer program control commands can also be stored in a machine-readable environment, which is capable of instructing a computer, other programmable data processing equipment or other devices to act in a specific way, as a result of which commands stored on a computer-readable medium form a product containing commands in which the / an action indicated by a block or blocks in structural diagrams and / or block diagrams.

Computer program control commands can also be downloaded to a computer, other programmable data processing equipment, or other devices to initiate the execution of a sequence of operational steps by a computer, other programmable equipment, or other devices in order to form a process implemented in the computer, while the commands executed by the computer or other programmable equipment, provide processes for the implementation of functions / actions indicated by a block or blocks on a string tural Schemes and / or block diagrams.

The structural diagrams and block diagrams shown in the drawings illustrate the architecture, functionality, and operation of possible embodiments of systems, methods, and computer software products according to various embodiments of one or more aspects of the present invention. In this regard, each block on structural diagrams or block diagrams can be represented by a certain module, segment or part of the code, which contains one or more executable commands to implement a given logical function (s). It should also be noted that in some alternative implementations, the functions indicated in the block may not be performed in the order in which they are presented in the drawings. For example, the functions indicated by two sequentially shown blocks, in fact, can be performed mainly simultaneously, or the functions can sometimes be performed in the reverse order, depending on the corresponding functionality. It should also be noted that each block in the block diagrams and / or structural diagrams and combinations of blocks in the block diagrams and / or structural diagrams can be implemented using specialized hardware systems that perform specified functions or actions, or through combinations of specialized hardware systems and computer teams.

In addition to the foregoing, one or more features of the present invention may be provided, proposed, applied, coordinated, maintained, etc. A service provider that offers user management. For example, a service provider is able to create, lead, maintain, etc. for one or more users, machine code and / or computing infrastructure in which one or more of the features of the present invention is executed. In response, the service provider may receive payment from the user based on a subscription agreement and / or monthly fee as examples. Additionally or alternatively, a service provider may receive payment for advertising content sold to one or more third parties.

According to one aspect of the present invention, an application may be deployed to perform one or more aspects of the present invention. As one example, application deployment includes the use of a computing infrastructure capable of performing one or more of the features of the present invention.

As one of the additional features of the present invention, the deployment of a computing infrastructure may include integrating computer-readable code into a computing system, the code in combination with a computing system capable of performing one or more features of the features of the present invention.

As another additional feature of the present invention, a method for integrating a computing infrastructure, comprising integrating computer-readable code into a computer system, can be proposed. A computer system comprises a computer-readable medium containing one or more features of the present invention. The code in combination with a computer system is capable of performing one or more of the features of the present invention.

Although various embodiments have been described above, they are merely examples. For example, one or more features of the present invention may be contained and used in computing environments of other architectures. As an example, one or more features of the present invention may be contained, used, and / or advantageously applied to servers other than zEnterprise servers. In addition, when converting a synchronous transmission to asynchronous transmission, other criteria may be considered in addition to whether a buffer is available. In addition, one or more of the features of the present invention can be used for any transfer of data from one isolated memory to another. Many other varieties are also possible.

In addition, one or more features of the present invention can be advantageously applied in other types of computing environments. As an example, a data processing system that is applicable for storing and / or executing program code and comprising at least two processors directly or indirectly connected to memory means via a system bus can be used. The memory elements include, for example, local memory used during the actual execution of the program code, mass memory and cache memory, which provides temporary storage of at least part of the program code to reduce the required number of cases of code extraction from the mass memory during execution.

I / O devices (including, without limitation, keyboards, displays, pointing devices, RAMs, tape drives, compact discs, multi-purpose compact discs, can be connected directly or indirectly through intermediate input-output controllers to the system) portable miniature hard drives and other storage media, etc.). Network adapters may also be associated with the system, allowing the data processing system to communicate with other data processing systems or remote printers or storage devices through intermediate private or public networks. Modems, cable modems, and Ethernet network cards are just a few of the available network adapters.

Consider figure 7, which presents the characteristic components of the main computer system 5000 for implementing one or more features of the present invention. A representative host computer 5000 includes one or more CPUs 5001 that communicate with a computer memory (i.e., central memory) 5002, as well as I / O interfaces with memory devices 5011 and networks 5010 for communicating with other computers or SANs, etc. . The 5001 CPU is compatible with an architecture that contains a structured instruction set and structured functionality. The CPU 5001 can perform dynamic translation of the address 5003 (DAT) to translate the program addresses (virtual addresses) into actual memory addresses. The DAT typically contains a fast address translation buffer (TLB) buffer 5007 for caching translations so that subsequent accesses to the computer's memory unit 5002 do not require a delay in address translation. Typically, cache 5009 is used between computer memory 5002 and processor 5001. Cache 5009 can be hierarchical and consists of a large capacity cache available for multiple CPUs and faster, lower-capacity caches (low level) between the large capacity cache and each CPU . In some cases, implementations of low-level caches are divided into separate low-level caches for fetching commands and accessing data. In one embodiment, an instruction fetching unit 5004 calls a command from memory 5002 via cache 5009. The instruction is decoded in instruction decoding unit 5006 and sent (with other instructions in some embodiments) to instruction execution unit or blocks 5008. Typically, several instruction execution units 5008 are used, for example, an arithmetic instruction execution unit, a floating point instruction execution unit, and a transition instruction execution unit. The command is executed by a block, which, depending on the need, accesses operands from registers or memory defined by commands. If access (loading or saving) to the operand is to be carried out from the memory 5002, the load / save block 5005 usually processes the access procedure under the control of the command being executed. Commands can be executed in hardware circuits or in the internal microcode (firmware) or using a combination of both.

As noted, the local (or main) storage device of a computer system stores information, as well as address, security, control and correction records. Some features of addressing include the address format, the concept of address spaces, different types of addresses, and how an address of one type translates to an address of another type. Some of the main storage devices have permanently subscribed cells. The primary storage device provides the system with a direct addressable storage device and fast data retrieval. Both data and programs must be loaded into the main storage device (from input devices), after which they can be processed.

The main storage device may contain one or more buffer storage devices of lower capacity with faster sampling, sometimes called caches. A cache is usually physically connected to a CPU or I / O processor. The physical design and use of various storage media in general does not affect the program, with the exception of performance.

Separate caches can be provided for instructions and operands stored in memory. The information is contained in the cache in the form of continuous bytes on an integer boundary called a block or line of cache data (or for short, a line). According to one of the models, a cache attribute retrieval command (EXTRACT CACHE ATTRIBUTE) can be provided, which gives the size of the cache line in bytes. According to one of the models, a prefetch data command (PREFETCH DATA) and a prefetch data command of relatively long length (PREFETCH DATA RELATIVE LONG) can also be provided to proactively select data from a storage device into a data or instruction cache or to free data from the cache.

The storage device is regarded as a long horizontal bit string. For most operations, the storage device is accessed sequentially from left to right. The bit string is divided into blocks of eight bits. The eight-bit block is called a byte and is the basic constructive block of all information presentation formats. The location of each byte in the storage device is identified by a uniquely determined non-negative integer, which is the location address of this byte or simply the address of the byte. Neighboring byte locations have consecutive addresses starting from left from 0 and sequentially following from left to right. Addresses are unsigned binary integers containing 24, 31, or 64 bits.

Information is exchanged between the storage device and the CPU or channel subsystem by transmitting one byte or group of bytes at a time. Unless otherwise specified, for example, in the z / Architecture ^{® system, a} stored byte group is addressed by the leftmost byte from the group. The number of bytes in the group is implied or directly specified by the operation. The byte group used by the CPU is called a field. The bits in each byte group, for example, in the z / Architecture ^{® system} , are sequentially numbered from left to right. The leftmost bits in z / Architecture ^{® are} sometimes referred to as the "highest" bits, and the rightmost bits are referred to as the "lower" bits. However, the bit numbers are not cell addresses of the storage device. Only byte addressing is possible. To operate with individual bits of a stored byte, access to the entire byte is performed. The bits in the byte are numbered from left to right from 0 to 7 (for example, in the z / Architecture ^{® system} ). The bits in the address can be numbered from 8 to 31 or from 40 to 63 in the case of 24-bit addresses, or from 1 to 31 or from 33 to 63 in the case of 31-bit addresses and from 0 to 63 in the case of 64-bit addresses. In any other fixed-length format of multiple bytes, the bits forming the format are sequentially numbered starting from 0. In order to detect errors and preferably correct them, one or more check bits can be transmitted with each byte or group of bytes. Such control bits are automatically generated by the machine and cannot be directly controlled by the program. Storage capacity is expressed in number of bytes. When the instruction operation code implies the length of the stored operand field, the field is considered to have a fixed length, which can be 1, 2, 4, 8, or 16 bytes. For some teams, longer fields may be implied. When the length of the stored field of the operand is not implied, but directly indicated, the field is considered to have a variable length. Variable length operands can vary in length in increments of 1 byte (or in the case of some instructions in increments of 2 bytes and other steps). When information is stored in the storage device, the contents of the locations of only those bytes that are included in the specified field are replaced, despite the fact that the width of the physical access path to the storage device may exceed the length of the stored field.

Some stored units of information must be on an integer boundary. As applied to a unit of information, a boundary is called integer when the address of its storage cell is a multiple of the length of the unit of information in bytes. Fields of 2, 4, 8, and 16 bytes in length on the integer boundary are given special names. Absolutely, it is a group of 2 consecutive bytes on a double-byte boundary and represents a basic constructive block of commands. A word is a group of 4 consecutive bytes on a four-byte boundary. A double word is a group of 8 consecutive bytes on an 8-byte boundary. A quadruple word is a group of 16 consecutive bytes on a 16-byte boundary. When half-words, words, double words and quadruples are indicated in the addresses of the memory cells, the binary representation of the address contains one, two, three or four rightmost zero digits, respectively. Teams must be on double-byte integer boundaries. The stored operands of most commands do not contain the requirement of placement at the borders.

In devices that implement separate caches for instructions and operands stored in memory, significant delays can occur if the program is stored in a cache line from which instructions are subsequently fetched, regardless of whether or not instructions that are subsequently fetched are saved when saved .

In one embodiment, the invention may be practiced by software (sometimes referred to as licensed internal code, firmware, microcode, millicode, picocode, etc., which is consistent with the present invention in all cases). As shown in FIG. 7, typically the processor 5001 of the main system 5000 gains access to the software code of the software system in which the present invention is embodied by means of long-term storage media 5011, such as a CD-ROM, a tape drive or a tape drive hard drives. The software system program code may be embodied in any of a variety of known environments for use with a data processing system, such as a floppy disk, hard disk drive, or CD ROM. The code may be distributed in such environments, or may be distributed to users from a computer memory 5002 or a storage device of one computer system over a network 5010 to other computer systems for use by users of such other systems.

The program code includes an operating system that controls the function and interaction of various nodes of a computer and one or more application programs. Typically, pages of program code are paged from storage medium 5011 to a relatively high-speed storage device 5002, in which it is available for processing by processor 5001. Methods and methods for translating software system code into memory, in physical environments, and / or distributing program code via networks are good known and will not be further considered in the description. Program code created and stored in a material environment (including without limitation electronic memory (RAM) modules, flash memory, compact discs, universal digital disks, magnetic tape, etc.) is often referred to as a “computer program product”. A medium containing a computer program product can usually be read by a data processing device, preferably in a computer system, for execution by a data processing device.

FIG. 8 illustrates a representative workstation or hardware server system in which the present invention may be practiced. The system 5020 shown in FIG. 8 includes a representative core computer system 5021, such as a personal computer, workstation, or server, including optional peripherals. Basic computer system 5021 has one or more processors 5026 and a bus for connecting processor (s) 5026 and other components of system 5021 and for communicating between them in known ways. A bus connects the processor 5026 with memory 5025 and long-term storage device 5027, which may contain a hard disk drive (for example, including any of the following: magnetic media, a compact disk, a universal digital disk and flash memory) or, for example, a magnetic drive tape. The system 5021 may also include a user interface adapter that connects the microprocessor 5026 to one or more interface devices via a bus, such as a keyboard 5024, a mouse 5023, a printer / scanner 5030, and / or other interface devices, which can be any user interface device, such as touch screen, optional numeric keypad, etc. The bus also connects a display 5022 through a display adapter, such as an LCD or a monitor with microprocessor 5026.

System 5021 can communicate with other computers or computer networks through a network adapter capable of communicating 5028 with network 5029. Examples of network adapters are communication channels, a ring network with a relay access, an Ethernet network, or modems. Alternatively, system 5021 may communicate using a wireless interface, such as a CDPD (Cellular Digital Packet Transmission System) card. System 5021 may be connected to other such computers on a local area network (LAN) or wide area network (WAN), or system 5021 may be a client connected by a client / server relationship with another computer, etc. All of these configurations, as well as associated communication equipment and software, are known from the art.

9, a data processing network 5040 is illustrated in which the present invention can be practiced. The data processing network 5040 may include many separate networks, such as a wireless network and a wired network, each of which may include many separate workstations 5041, 5042, 5043, 5044. In addition, as is well known to specialists in this field of technology, may include one or more LANs, which may include many intelligent workstations associated with the main processor.

Figure 9 also shows that mainframes or servers, such as a gateway (client-server 5046) or application server (remote server 5048, which can access the data store, and can also be accessed directly from the working network, can also enter the network) station 5045). Gateway 5046 serves as an entry point to each individual network. A gateway is required when connecting one network protocol to another. Gateway 5046 may preferably be connected to another network (e.g., the Internet 5047) via a communication link. Gateway 5046 can also be directly connected to one or more workstations 5041, 5042, 5043, 5044 using a communication line. The gateway can be implemented using the IBM eServer ™ System z ^® server manufactured by International Business Machines Corporation.

As shown in FIGS. 8 and 9, access to the software code of a software system in which the present invention may be implemented may be provided by processor 5026 of system 5020 via long-term storage media 5027, such as a ROM on a CD, or a hard disk drive . The software system program code may be embodied in any of a variety of known environments for use with a data processing system, such as a floppy disk, hard disk drive, or CD ROM. The code may be distributed in such environments, or may be distributed to users 5050, 5051 from the computer memory or storage device of one computer system over a network to other computer systems for use by users of such other systems.

Alternatively, the program code may be embodied in memory 5025 with access to it for processor 5026 using the processor bus. Such program code implements an operating system that controls the function and interaction of various nodes of a computer and one or more application programs 5032. Typically, pages of program code are paged from storage media 5027 to high-speed storage device 5025, in which it is available for processing by processor 5026. Methods and methods for translating program code of a software system into memory, in physical environments, and / or distributing program code through networks x well known and will not be further considered in the description. Program code created and stored in a material environment (including without limitation electronic memory (RAM) modules, flash memory, compact discs, universal digital disks, magnetic tape, etc.) is often referred to as a “computer program product”. A medium containing a computer program product can usually be read by a data processing device, preferably in a computer system, for execution by a data processing device.

The cache that is most readily available to the processor (usually faster and less voluminous than other processor caches) is the lower level cache (L1 or level 1), and the main storage device (main memory) is the highest level cache (L3 in case of 3 levels). The lower level cache is often divided by the instruction cache (I-cache), which stores the machine instructions for execution, and the data cache (D-cache), which stores the operands stored in memory.

10 illustrates one embodiment of a processor 5026. Typically, one or more levels of cache 5053 are used to buffer memory blocks and improve processor performance. Cache 5053 is a high-speed buffer in which data lines are stored in memory in cache lines, which will probably be used. Typical cache data lines contain 64, 128, or 256 bytes of data in memory. Separate caches are often used for command caching and data caching. The consistency of caches (synchronization of copies of lines in memory and in caches) is often ensured by various tracking algorithms ("snoop"), well known in the art. The main storage device 5025 of the processor system is often referred to as a cache. In a processor system having a level 4 cache 5053, the main storage device 5025 is sometimes called a level 5 cache (L5), because it is usually faster and is only part of a non-volatile memory device (RAM, tape memory, etc.), which is available for a computer system. The main storage device 5025 "caches" data pages that are pumped into and pumped out from the main storage device 5025 by the operating system.

A software counter (instruction counter) 5061 tracks the address of the current command to execute. The instruction counter on a z / Architecture-based processor is 64-bit, and it can be truncated to 31 or 24 bits in order to support pre-existing addressing restrictions. Since the command counter is usually embodied in the program status word (PSW) of the computer, it is saved when the context switches. Accordingly, an executable program with a command counter can be interrupted, for example, by the operating system (when switching context from the software environment to the operating system environment). The PSW of the program supports reading the command counter while the program is inactive, and the command counter (in PSW) of the operating system is used at runtime. Typically, the instruction counter is incremented by the number of bytes of the current instruction. RISC commands (based on calculations with a reduced set of instructions) usually have a fixed length, while CISC commands (based on calculations with a full set of instructions) usually have a variable length. The commands used in the IBM z / Architecture system are CISC commands that are 2, 4, or 6 bytes long. The counter 5061 of the instruction is changed, for example, as a result of a context switching operation or a selected transition operation according to a transition command. During the context switching operation, the current instruction counter reading is stored in the program status word along with other information about the status of the program being executed (such as condition codes), and a new instruction counter reading is loaded, indicating the command of the new program module to execute. The operation of the selected transition is performed to allow the program to make decisions, or to execute a program cycle by loading the result of the transition command into the counter 5061 of the instructions.

Typically, instruction fetch unit 5055 is used to fetch instructions on behalf of processor 5026. The fetch unit selects the "next consecutive commands", target commands from the commands of the selected transition or the first commands of the program following the context switch. In modern teams sampling units, sampling methods are often used to pre-select teams by assumption, based on the likelihood of using teams that were pre-sampled. For example, a fetch unit can fetch 16 bytes of a command containing the next sequential command and additional bytes of the following commands.

Then, the called instructions are executed by the processor 5026. In one embodiment, the called command (s) are transmitted to the block 505 scheduling unit. The scheduling unit decodes the instruction (s) and sends information about the decoded instruction (s) to the corresponding units 5057, 5058, 5060. The execution unit 5057 usually receives information about the decoded arithmetic instructions from the instruction selection unit 5055 and performs arithmetic operations with the operands in accordance with the operation code contained in the command. The operands are provided to execution unit 5057, preferably from memory 5025, structured registers 5059, or from the immediate field of an executable instruction. The stored execution results are stored in memory 5025, registers 5059, or in other machine hardware (such as control registers, PSW registers, etc.).

The processor 5026 typically has one or more blocks 5057, 5058, 5060, performing the function of the command. As shown in FIG. 11A, the execution unit 5057, through the interface logic 5071, can communicate with structured shared registers 5059, the decoding / scheduling unit 5056, the load / save unit 5060, and other processor units 5065. Several register circuits may be used in the execution unit 5057 5067, 5068, 5069 for storing information that the arithmetic logic device (ALU) 5066 will work with. ALU performs arithmetic operations such as addition, subtraction, multiplication and division, as well as logs RP G functions such as AND, OR and XOR, rotation and displacement. ALU preferably supports design-specific specialized operations. In other schemes, other structured means 5072 may be provided, including, for example, condition codes and a recovery support logic. Typically, the result of an ALU operation is stored in an output register circuit 5070, from which it can be transferred to a number of other processing functions. Although there are many designs of processors, the present description is intended only to provide an understanding of one embodiment.

For example, the addition command is executed by the execution unit 5057, which has arithmetic and logical functionality, and, for example, the floating-point command is executed by the floating-point unit, which has specialized floating-point capabilities. The execution unit preferably works with the operands indicated by the command by executing a function specified by the operation code as applied to the operands. For example, an addition instruction may be executed by execution unit 5057 in relation to operands found in two registers 5059 indicated in register fields of the instruction.

Block 5057 execution performs arithmetic addition of two operands and stores the result in the third operand, which may be a third register or one of two source registers. The execution unit preferably uses an arithmetic logic device (ALU) 5066, capable of performing a number of logical functions, such as offset, rotation. AND, OR, and exclusive OR, as well as a number of algebraic functions, including any of the following functions: addition, subtraction, multiplication, division. Some ALU 5066 are designed for scalar operations, and some - for floating point operations. Depending on the architecture, the data may have a reverse byte order (when the least significant byte corresponds to the most significant byte address) or a direct byte order (when the least significant byte corresponds to the lower byte address). IBM z / Architecture uses reverse byte ordering. Depending on the architecture, the field of signed numbers can be represented as a direct code, additions to one, or additions to two. A number in the form of an addition to two is advantageous in the sense that the ALU does not need to support the possibility of subtraction, since with a negative or positive addition to two in the ALU, only addition is required. Numbers are usually described in abbreviated form, in which a 12-bit field determines the address of a block of 4096 bytes and is usually described, for example, in the form of a 4 kilobyte block.

As shown in FIG. 11B, the information contained in the transition instruction for executing the transition instruction is typically transmitted to the transition unit 5058, which often uses a transition prediction algorithm, such as transition history table (TPI) 5082, to predict the outcome of the transition before other conditional operations are completed. The target of the current branch instruction is invoked and executed by assumption until conditional operations are completed. When the conditional operations are completed, the assumptions made transition instructions are completed or discarded based on the conditional operation and the expected outcome. A typical transition instruction may include checking condition codes and moving to the destination address if the condition codes meet the requirements of the transition instruction, and the destination address may be calculated based on several numbers, including, for example, numbers from register fields or the direct instruction field. At transition block 5058, an ALU 5074 may be applied having a plurality of input register circuits 5075, 5076, 5077 and an output register circuit 5080. Transition unit 5058, for example, may communicate with common registers 5059, decode scheduling unit 5056, or other schemes 5073.

The execution of a group of commands may be interrupted for a number of reasons, including, for example, a context switch initiated by the operating system, an exception or an error during program execution leading to a context switch, an I / O interrupt signal leading to a context switch, or multi-threaded operation programs (in a multi-threaded environment). The context switch is preferably used to save information about the status of the currently executing program and then to download information about the status of another called program. Status information may be stored, for example, in hardware registers or in memory. The status information preferably includes a command counter reading indicating the next command to execute, condition codes, information about converting memory data, and contents of a structured register. Context switching may be performed by hardware circuits, application programs, operating system programs, or hardware-software code (microcode, picocode, or licensed internal code (LIC), individually or in combination).

The processor accesses the operands in accordance with methods defined by the instructions. A command may contain an immediate operand that uses the value of a part of the command, may contain one or more register fields that directly indicate general purpose registers or special purpose registers (for example, floating point registers). The command may use implied registers, denoted by the operation code field as operands. The command can use memory cells for operands. The memory cell for the operand can be provided with a register, direct field, or a combination of registers and direct field, an example of which is a long-range offset tool based on the z / Architecture system, in which the command determines the base register, index register and direct field (offset field), which are summed with the purpose of obtaining, for example, the address of the operand in memory. A cell in this case means a cell of the main memory (main storage device), unless otherwise indicated.

As shown in FIG. 11B, the processor accesses the memory using the load / save unit 5060. The load / save unit 5060 may perform a load operation by obtaining the address of the target operand in memory 5053 and load the operand into register 5059 or another memory location 5053, or may perform a save operation by obtaining the address of the target operand in memory 5053 and store data obtained from register 5059 or another memory cell 5053, in the target operand cell in the memory 5053. The load / save block 5060 can act on the assumption and access the memory in a sequence that does not match the sequence Most of the commands, however, the load / save block 5060 should provide for programs the visibility of command execution in order. The load / save unit 5060 can communicate with the general registers 5059, the decoding / scheduling unit 5056, the cache / memory interface 5053, or other elements 5083 and contains various register circuits, ALU 5085, and control logic 5090 for calculating the addresses of the memory cells and providing a serial stream to maintain the order of operations. Some operations may be performed out of order, but the load / save unit provides functionality so that the out-of-order operations appear for the program to be completed in order, as is well known in the art.

The addresses that the application “sees” are preferably often referred to as virtual addresses. Sometimes virtual addresses are referred to as “logical addresses” and “executive addresses”. These virtual addresses are virtual in the sense that they are redirected to a physical memory cell using one of a number of dynamic address translation (DAT) technologies, including, without limitation, simply assigning an offset value to a virtual address, translating a virtual address through one or more translation tables, which preferably comprise at least a segment table and a page table individually or in combination, preferably a segment table containing a record indicating the table tzu page. The z / Architecture system provides a translation hierarchy that includes the first region table, the second region table, the third region table, the segment table, and the optional page table. Address translation efficiency is often improved by using the Fast Address Translation (TLB) buffer, which contains entries that map the virtual address of the corresponding physical memory location. Entries are created when the DAT translates a virtual address using translation tables. Then, upon subsequent use of the virtual address, an entry from the high-speed TLB can be used instead of accessing the slow sequential translation tables. A number of substitution algorithms can manage the contents of a TLB, including the oldest used page replacement algorithm (LRU).

In the case where the processor is a processor of a multiprocessor system, each processor is responsible for maintaining shared resources, such as I / O, caches, TLBs and memory, mutually locked to ensure consistency. Typically, tracking technologies are used to maintain cache consistency. To facilitate sharing, each cache line can be marked in the tracking environment as being in one of the following states, including the sharing state, exclusive state, changed state, invalid state, etc.

The input / output units 5054 (FIG. 10) provide the processor with means for connecting to peripheral devices, including, for example, tape drives, disk drives, printers, displays, and networks. I / O blocks are represented in a computer program by software drivers. On mainframes, such as System z ^® manufactured by IBM ^® , mainframe I / O units are channel adapters and adapters of open systems and provide communication between the operating system and peripheral devices.

In addition, one or more features of the present invention can be advantageously applied in other types of computing environments. As an example, an environment may contain an emulator (for example, software or other emulation mechanisms) in which a specific architecture is emulated (including, for example, executing commands, structured functions such as address translation, and structured registers) or its abridged version (for example, in your own computer system having a processor and memory). In such an environment, one or more features of the present invention may be implemented due to one or more emulating functions of the emulator, despite the fact that the computer on which the emulator is running may have an architecture that is different from the emulated capabilities. As one example, in emulation mode, a specific emulated command or operation is decoded, and a corresponding emulating function is created in order to implement a separate command or operation.

In an emulating environment, the host computer contains, for example, memory for storing instructions and data; a command fetch unit for fetching commands from memory and optionally local buffering selected commands; an instruction decoding unit for receiving instructions from an instruction fetching unit and determining the type of instructions that have been selected; and a command execution unit for executing instructions. Execution may include loading data from memory into a register; saving data from the register in memory; or performing an arithmetic or logical operation of any type determined by the decoding unit. In one example, each block is implemented by software. For example, the operations performed by blocks are implemented as one or more subprograms in the emulator software.

In the mainframe, in particular, structured machine instructions are used by programmers, usually modern “C” programmers, through a compiling application. These instructions stored in the storage medium may be executed in its own server IBM ^® System commands based on the z / Architectwe ^® or alternatively in other architectures based machines. They can be emulated in existing and future IBM ^® mainframe servers and in other IBM ^® machines (for example, Power Systems servers and System x ^® servers). They can run on a Linux operating system, a variety of machines using hardware production IBM ^®, Intel ^®, AMD ™, and others. In addition to running this hardware based on Z / Architecture ^® , Linux can also be used, as well as machines using Hercules, UMX or FSI emulation (Fundamental Software, Inc), when the execution usually takes place in emulation mode. In emulation mode, the emulating software is executed by its own processor, which emulates the architecture of the emulated processor.

A proprietary processor typically runs emulation software, which is firmware or its own operating system, to emulate an emulated processor. The emulation software is responsible for fetching and executing the architecture commands of the emulated processor. The emulation software maintains a counter of emulated instructions for tracking the boundaries of instructions. Emulating software can sample one or more emulated machine instructions at a time and convert one or more emulated machine instructions into the corresponding group of its own machine instructions for execution by its own processor. These converted commands can be cached, which speeds up the conversion. However, emulation software must support the rules of the architecture of the emulated processor in order to ensure the correct operation of operating systems and applications written for the emulated processor. In addition, the emulation software must provide the resources indicated by the architecture of the emulated processor, including without limitation control registers, general registers, floating point registers, dynamic address translation function, including segment tables and page tables, for example, interrupt mechanisms, context switching mechanisms , True Time Clock (TOD), and structured interfaces with I / O subsystems so that the operating system or application is designed to work in the emulated processor, it can be run in its own processor that emulates the software.

The particular emulated command is decoded, and a subroutine is called to perform the function of a separate command. The function of emulating software that emulates the function of an emulated processor is implemented in a subroutine or driver in the "C" language or in some other way to provide a driver for specific hardware, available to specialists in this field of technology who have read the description of the preferred embodiment. In various patents that offer software and hardware emulation, including, but not limited to, US Pat. instructions on a target processor "issued to Scalzi et al .; US patent 5574873 entitled "Decoding guest instruction to directly access emulation routines that emulate the guest instructions", issued in the name of Davidian and others; US 6308255, entitled "Symmetrical multiprocessing bus and chipset used for coprocessor support allowing non-native code to run in a system", issued in the name of Gorishek et al .; US patent 6463582 entitled "Dynamic optimizing object code translator for architecture emulation and dynamic optimizing object code translation method", issued in the name of Lethin and others; US patent 5790825 entitled "Method for emulating guest instructions on a host computer through dynamic recompilation of host instructions", issued in the name of Eric Traut; and many others, various well-known methods of emulating a command format structured for a different machine in a target machine are illustrated, available to those skilled in the art.

12 illustrates one example of a prior art emulating host computer system 5092 that emulates a host computer system 5000 ′ having a host architecture. The main processor (CPU) 5091 in the main computer system 5092 emulation is the main processor (or virtual main processor) emulation, which is a processor 5093 emulation with the structure of its own teams, different from the command structure of the processor 5091 of the main computer 5000 '. The host computer system 5092 emulation has a memory 5094, available for the processor 5093 emulation. In an embodiment, the memory 5094 is divided into a memory 5096 of the host computer and a memory 5097 of emulation programs. Memory 5096 of the host computer is available for programs of the emulated host computer 5092, depending on the architecture of the host computer. The emulation processor 5093 executes its own instructions of a structured instruction system, the structure of which is different from the instruction structure of the emulated processor 5091 and which are extracted from the memory 5097 of the emulation programs, and can select the main command for execution from the program in the memory of the main computer 5096 by applying one or more commands from sequence control programs and sampling / decoding, which can decode the selected main command (s) and determine the program A team emulate the function of the selected main team. Other tools that are provided for in the architecture of the host computer system 5000 'can be emulated by structured software programs, including tools such as general purpose registers, control registers, support for dynamic address and input / output translation subsystems, and processor cache. Emulation programs can also use the features available in the emulation processor 5093 (such as general registers and dynamic virtual address translation) to improve the performance of emulation programs. Special software and unloading mechanisms may also be provided to facilitate the 5093 processor emulating the function of the host computer 5000 ′.

The terminology used in the description is intended to describe only particular embodiments, and not to limit the invention. It is understood that the singular forms used in the description also include the plural, unless the context clearly dictates otherwise. Additionally, it is understood that the terms “comprises” and / or “comprising” used in the description mean the presence of the indicated features, numbers, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, numbers, steps, operations, elements, components and / or groups thereof.

It is intended that the corresponding structures, materials, actions and equivalents of all elements of the “means or step plus function” of the following claims, if any, include any structure, material or action to perform a function in combination with other specifically claimed means. The description of one or more features of the present invention is presented as an illustration and is not intended to exhaust or limit the invention to the disclosed form. Numerous modifications and variations are indisputable for those skilled in the art without departing from the scope and spirit of the invention. The selected and described embodiment is intended to best explain the principles of the invention and its practical application, as well as to enable those skilled in the art to understand the invention, as various embodiments are provided with various modifications designed for a particular application.

Claims (31)

1. Non-volatile computer-readable storage medium that stores instructions read and executed by a data processing device for implementing a method for providing communication in a communication environment, including:
obtaining, by the processor of the communication medium, from the sender of the communication medium, prior permission for converting the synchronous data transfer to asynchronous data transfer, the preliminary permission including obtaining an indication of a memory unit for monitoring the asynchronous data transfer,
receipt by the processor from the sender of a request for data transmission to the recipient of a communication medium,
initiation by the processor of data transmission to the recipient using synchronous data transfer,
the establishment by the processor of the need to convert synchronous data transfer to asynchronous data transfer, and
the automatic conversion performed by the processor at the specified setting by the synchronous data transfer to the asynchronous data transfer to complete the data transfer to the recipient, while the automatic conversion is independent of any actions of the sender, except for prior permission. 2. The computer-readable storage medium according to claim 1, wherein said establishment includes setting a delay in receiving data by the recipient while the data is being transmitted, and the automatic conversion of the synchronous data transfer to the asynchronous data transfer in this case, to complete the data transfer at that time, when the recipient is able to receive data. 3. The computer-readable storage medium according to claim 2, in which the automatic conversion includes:
saving the request in the memory block,
queuing a memory block,
establishing the ability of the recipient to receive data, and
data transfer to the recipient using a memory block. 4. The computer-readable storage medium according to claim 3, wherein establishing the ability of the recipient to receive data includes determining whether the recipient has an empty buffer for receiving data. 5. The computer-readable storage medium of claim 3, wherein the method further includes notifying the sender of the completion of the transmission. 6. The computer-readable storage medium according to claim 5, in which the notification of completion of the transfer includes a message of the address of the memory block in the completion queue in the memory available to the sender. 7. The computer-readable storage medium according to claim 6, wherein the method further includes generating an interrupt for the sender when the address in the completion queue is reported. 8. The computer-readable storage medium according to claim 2, in which the establishment of a delay in receiving data by the recipient includes establishing the inaccessibility of the receive buffer for receiving data. 9. The computer-readable storage medium according to claim 1, wherein the method further comprises receiving another request from the sender, wherein the other request is to be transmitted synchronously to another recipient until completion of the asynchronous transfer of the request to the recipient. 10. The computer-readable storage medium according to claim 1, in which the method further includes receiving one or more additional requests from the sender to complete the asynchronous transfer of data to the recipient, while the data of one or more additional requests can be transmitted synchronously or asynchronously to one or more recipients. 11. The computer-readable storage medium according to claim 1, wherein the method further includes maintaining the order of receipt of data by the recipient when converting synchronous data transfer to asynchronous data transfer. 12. A computer system for providing communication in a communication environment, comprising a memory and a processor communicating with the memory, wherein the computer system is configured to implement a method including:
obtaining, by the processor of the communication medium, from the sender of the communication medium, prior permission for converting the synchronous data transfer to asynchronous data transfer, the preliminary permission including obtaining an indication of a memory unit for monitoring the asynchronous data transfer,
receipt by the processor from the sender of a request for data transmission to the recipient of a communication medium,
initiation by the processor of data transmission to the recipient using synchronous data transfer,
the establishment by the processor of the need to convert synchronous data transfer to asynchronous data transfer, and
the automatic conversion performed by the processor at the specified setting by the synchronous data transfer to the asynchronous data transfer to complete the data transfer to the recipient, while the automatic conversion is independent of any actions of the sender, except for prior permission. 13. The computer system of claim 12, wherein said establishment includes setting a delay in receiving data by the recipient while the data is being transmitted, and the automatic conversion of the synchronous data transfer to the asynchronous data transfer to complete the data transfer at the time when the receiver is able to receive data. 14. The computer system of claim 13, wherein the automatic conversion includes:
storing the request in the memory block, placing the memory block in the queue of the receiver, establishing the ability of the receiver to receive data, and transmitting data to the receiver using the memory block. 15. The computer system of claim 14, wherein determining the recipient's ability to receive data includes determining whether the recipient has an empty buffer for receiving data. 16. The computer system of claim 14, wherein the method further includes notifying the sender of the completion of the transmission. 17. The computer system according to claim 16, in which the notification of completion of the transmission includes the message address of the memory block in the completion queue in the memory available to the sender. 18. The computer system according to claim 17, in which the method further includes generating an interrupt for the sender when the address in the completion queue is reported. 19. The computer system according to p. 12, in which the method further includes receiving another request from the sender, while the other request is subject to synchronous transmission to another recipient until completion of the asynchronous transfer of the request to the recipient. 20. The computer system according to p. 12, in which the method further includes receiving one or more additional requests from the sender to complete the asynchronous data transfer to the recipient, while the data of one or more additional requests can be transmitted synchronously or asynchronously to one or more recipients. 21. A method of providing communication in a communication environment, including:
obtaining, by the processor of the communication medium, from the sender of the communication medium, prior permission for converting the synchronous data transfer to asynchronous data transfer, the preliminary permission including obtaining an indication of a memory unit for monitoring the asynchronous data transfer,
receipt by the processor from the sender of a request for data transmission to the recipient of a communication medium,
initiation by the processor of data transmission to the recipient using synchronous data transfer,
the establishment by the processor of the need to convert synchronous data transfer to asynchronous data transfer, and
the automatic conversion performed by the processor at the specified setting by the synchronous data transfer to the asynchronous data transfer to complete the data transfer to the recipient, while the automatic conversion is independent of any actions of the sender, except for prior permission. 22. The method according to p. 21, wherein said establishment includes setting a delay in receiving data by the recipient while the data is being transmitted, and the automatic conversion of the synchronous data transfer to the asynchronous data transfer in this case, to complete the data transfer at the time the recipient able to receive data. 23. The method according to p. 22, in which the automatic conversion includes:
saving the request in the memory block,
placing the memory block in the queue of the recipient, establishing the ability of the recipient to receive data, and
data transfer to the recipient using a memory block. 24. The method of claim 23, wherein determining the recipient's ability to receive data includes determining if the recipient has an empty buffer for receiving data. 25. The method of claim 23, further comprising notifying the sender of the completion of the transmission. 26. The method according to p. 25, in which the notification of the completion of the transmission includes the message address of the memory block in the completion queue in the memory available to the sender. 27. The method of claim 26, further comprising generating an interrupt for the sender when the address in the completion queue is reported. 28. The method according to p. 22, in which the establishment of a delay in receiving data by the recipient includes establishing the inaccessibility of the receiving buffer for receiving data. 29. The method according to p. 21, further comprising receiving another request from the sender, the other request being synchronously transmitted to another recipient until completion of the asynchronous transfer of the request to the recipient. 30. The method according to p. 21, further comprising receiving one or more additional requests from the sender to complete the asynchronous transfer of data to the recipient, while the data of one or more additional requests can be transmitted synchronously or asynchronously to one or more recipients. 31. The method according to p. 21, further comprising maintaining the order of receipt of data by the recipient when converting synchronous data transfer to asynchronous data transfer.

Images