US20040078507A1 - Managing bus transaction dependencies - Google Patents

Managing bus transaction dependencies Download PDF

Info

Publication number
US20040078507A1
US20040078507A1 US10/674,316 US67431603A US2004078507A1 US 20040078507 A1 US20040078507 A1 US 20040078507A1 US 67431603 A US67431603 A US 67431603A US 2004078507 A1 US2004078507 A1 US 2004078507A1
Authority
US
United States
Prior art keywords
command
transaction
queue
buffer space
broadcast
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10/674,316
Inventor
Zohar Bogin
Serafin Garcia
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to US10/674,316 priority Critical patent/US20040078507A1/en
Publication of US20040078507A1 publication Critical patent/US20040078507A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14Handling requests for interconnection or transfer
    • G06F13/20Handling requests for interconnection or transfer for access to input/output bus
    • G06F13/24Handling requests for interconnection or transfer for access to input/output bus using interrupt
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38Information transfer, e.g. on bus
    • G06F13/382Information transfer, e.g. on bus using universal interface adapter
    • G06F13/385Information transfer, e.g. on bus using universal interface adapter for adaptation of a particular data processing system to different peripheral devices

Definitions

  • the invention pertains generally to computer systems. In particular, it pertains to avoiding deadlocks and livelocks in the dispatching and execution of bus transactions.
  • FIG. 1 shows a portion of a conventional computer system containing such a centralized I/O controller 10 , which controls the transfer of commands and data between processors 11 , 12 , graphics controller 13 , memory controller 14 , and peripheral bus controller 15 .
  • processors 11 , 12 graphics controller 13 , memory controller 14 , and peripheral bus controller 15 .
  • peripheral bus controller 15 Each is connected to I/O controller 10 over a separate interface 21 , 23 , 24 and 25 , respectively, each of which may be a bus.
  • FIG. 2 shows a more detailed view of I/O controller 10 .
  • a request from one of the CPU's 11 , 12 to initiate a transaction is decoded by request decoder 111 , which loads the request into In-Order Queue (IOQ) 112 .
  • IOQ 112 keeps the various phases of multiple transactions executing in the correct order, so that a given phase of a subsequent transaction will not be executed before the same phase of a preceding transaction. This is done by placing the request for the transaction into dispatch queue 113 and response queue 115 , and for memory requests, into snoop queue 117 and snoop response queue 119 . Although shown and discussed as four separate queues, these may actually be a single queue with four separate pointers indicating which location is considered to be the exit of the queue for each function.
  • an indicator When an indicator exits dispatch queue 113 , it triggers dispatcher 114 to send the transaction to the correct interface 23 , 24 or 25 , through the associated command queue 130 , 140 , or 150 , which queues up the transaction before it is presented to the respective interface.
  • the transactions are “drained” from the command queues as the transactions are serviced by the receiving circuitry.
  • the target device When the target device responds, that response clears the associated request from the exit of response queue 115 . If the request is to a memory system with cache, a snoop function and its response are also processed through queues 117 , 119 . Thus a transaction is completed only when the relevant request has been cleared from all queues in IOQ 112 .
  • a delayed transaction response includes a retry response, but the I/O controller 10 and the target interface also commit resources to the eventual retry, thus blocking those resources from other transactions and potentially forcing those other transactions to be reattempted. Only one transaction may be delayed at a time.
  • a deferred response does not require a reattempt by the initiator—the I/O controller notifies the initiator that the target device will provide the requested data when it is ready, and the I/O controller will pass the data on to the initiator using a special transaction called a deferred reply.
  • the transaction is complete when the request is deferred, the operation continues until the deferred reply, and various resources may remain committed until the deferred reply.
  • the request is cleared from the queues in IOQ 112 when the retry/delay/defer status is created by the response from the I/O controller to the requester.
  • a request can be initially assigned an identifier, so that if it is reattempted with the same identifier, all affected devices can correlate the reattempt with the original request.
  • a deadlock occurs when the output of two or more queues cannot be cleared because the data to initiate a clearing action in each is blocked within the other queue.
  • a livelock occurs when a requested transaction cannot make progress in one queue because it depends on another queue which, although moving, is always full and thereby repeatedly forcing some type of reattempt.
  • a livelock creates an ongoing bottleneck in the system, which may eventually go away in normal operation after an unacceptably long time, while a deadlock causes a blockage in the system that will not go away without some type of overt corrective action.
  • deadlocks and livelocks are generic to a system and can be avoided through proper overall system design. Others are only seen during specific, unusual circumstances and must be addressed with a customized solution on a case-by-case basis.
  • FIG. 1 shows a system of the prior art.
  • FIG. 2 shows an I/O controller of the prior art.
  • FIG. 3 shows an I/O controller of the invention.
  • FIG. 4 shows a flow chart for handling a broadcast transaction.
  • FIG. 5 shows a flow chart for using a bail-out timer.
  • FIG. 6 shows a flow chart for handling a locked request to PAM space.
  • One or more embodiments of the invention are directed to avoiding various types of deadlock/livelock situations through the use of delayed or deferred transactions. These embodiments are explained in more detail below.
  • a broadcast command is a command that is recognized by all (or at least many) of the devices that receive it.
  • a broadcast command allows a general-purpose command to be sent to all relevant devices without having to maintain a list of those devices, and without having to send individually-addressed messages to each device on the list.
  • a broadcast command typically contains a destination address that is recognized by all intended target devices. Since a broadcast command may be seen and used by many devices, it is generally not feasible for the sender to determine if all relevant devices have responded, and in some embodiments no response at all is required.
  • An End-of-Interrupt command is a broadcast command that indicates the CPU has completed processing of an interrupt. It can be broadcast to all buses where an interrupt controller (i.e., a device that can generate an interrupt) might be attached. For proper execution, space for this command must be simultaneously available in all downstream command queues 130 , 140 when the command is dispatched. If one or more downstream command queues is full or otherwise unavailable, it may not be feasible for the IOQ to hold this command while waiting for the downstream command queues to drain, since the IOQ itself may contain the request, or be blocking the CPU or upstream processor bus request, needed to initiate draining of the blocked downstream command queue, thus creating a deadlock. On the other hand, forcing a retry of the EOI command can create a livelock because other competing commands, such as those not requiring multiple simultaneous queue space availability, can repeatedly refill the downstream command queues before the EOI is reattempted.
  • FIGS. 3 and 4 illustrate one embodiment of the invention, which uses the delayed transaction mechanism to guarantee available resources for the EOI request.
  • each of queues 130 , 140 provide an indicator back to dispatcher 114 when they are full so that dispatcher 114 will not dispatch a transaction into a queue that has no place to put it. If one or more downstream command queues is full, dispatcher 114 can hold the EOI transaction while waiting for the queues to drain, provided no other commands are pending. However, if any other CPU request is received, I/O controller 10 can use its internal logic to terminate the transaction by sending a delayed transaction response back to the requestor.
  • a delayed transaction response is essentially a retry response, except the necessary resources are reserved for the eventual retry attempt.
  • downstream command queue space is reserved. Therefore, other requests requiring one of the downstream command queues can themselves be directed to retry as long as the delayed transaction is pending. This prevents other requests from repeatedly filling the downstream command queues, and allows these queues to drain.
  • ‘other requests’ also includes other EOI commands, which can be differentiated from the subject EOI command by their transaction identifiers.
  • FIG. 4 shows a procedure that can be followed by this process.
  • a broadcast transaction is initiated by loading it into IOQ 112 .
  • dispatcher 114 determines at step 410 if any of the downstream command queues 130 , 140 are full. If none are full, i.e., if there is space in all downstream command queues hold a transaction, the broadcast transaction is dispatched to the downstream command queues at step 420 , and any subsequent transactions are also handled normally at step 430 . However, if step 410 determines that at least one of the downstream command queues is full, the IOQ is checked at step 440 to see if any other requests are pending.
  • the system loops through steps 410 and 440 while waiting for the command queues to drain so the broadcast transaction can be dispatched. If another request is detected in the IOQ, either before or during this looping operation, a delayed transaction response is issued to the requestor at step 450 .
  • the downstream command queues are now reserved for the eventual reattempt of the broadcast transaction, and any other transactions that subsequently reach dispatcher 114 and require one of the downstream command queues 130 , 140 can be given a retry response at step 460 to prevent them from filling up the command queues
  • the broadcast transaction is eventually retried. As before, if all command queues have space, the retried broadcast transaction is dispatched and any subsequent transactions are then handled normally. If at least one of the downstream command queues is still full, the delayed transaction cycle repeats until all queues have space to accept the broadcast command.
  • a deadlock can also occur when the IOQ depth is configured to 1 (meaning each of queues 113 , 115 , 117 and 119 can only contain one entry—in certain situations this is desirable), and a non-postable downstream transaction's completion is blocked by a downstream agent's need to access main memory via processor bus 21 .
  • a non-postable transaction is a transaction that must wait for a response, so IOQ 112 must wait for a response before permitting any other transactions to proceed.
  • the non-postable transaction cannot be deferred because the I/O controller's conventional defer policy requires that another request be present in the IOQ before it defers the current request at the outlet of the dispatch queue. Since another request cannot arrive when the IOQ is set to 1, this condition for deferral will never be true.
  • Timer 315 in FIG. 3 starts counting whenever a deferrable request is dispatched.
  • Deferrable transactions can include, for example, non-locked CPU-to-peripheral reads and CPU-to-peripheral I/O type writes. If the transaction is completed (i.e., the response is received from the destination device) before the timer expires, the timer can be disabled, as it is no longer needed. However, if the timer expires before a response is received from the destination device, the transaction can be unconditionally deferred, thus “bailing out” of the original transaction.
  • the expiration time on the timer can be programmable, and the timer may be enabled and disabled via configuration programming.
  • This approach has the advantage of initiating the deferred state only if it is potentially needed to resolve a deadlock or livelock. If the transaction executes in a reasonable time, the timer never expires and the transaction is never deferred. Since deferral creates delays in execution, this process avoids unnecessary delays. On the other hand, if the transaction does not execute in a reasonable time, then a deadlock or livelock situation is likely, and the deferral acts to break the deadlock/livelock. While the above description assumes an IOQ depth of 1, the bail-out timer can also be used when the IOQ depth is greater than 1 for the purpose of avoiding other deadlock or livelock conditions.
  • FIG. 5 shows a procedure that can be followed by this process.
  • the bail-out timer is started at step 510 .
  • the system will then loop through steps 520 and 530 while waiting for a response to be received or the timer to expire. If a response is received at step 520 before the timer expires, the timer is stopped at step 550 and processing continues normally at step 560 . However, it the timer expires at step 530 before the response is received, a deferred response is issued to the requestor at step 540 , whereupon the timer is stopped and processing continues normally for a deferred transaction.
  • a “locked” command is one that locks up the required resources, making them unavailable to other transactions, until a given sequence of commands completes.
  • a locked request from a CPU to a peripheral controller might lock up processor bus 21 , peripheral downstream command queue 150 , peripheral bus 25 , and the peripheral controller, thus preventing other devices from using those resources until the locked command has completed and the resources are unlocked.
  • an initial locked read is converted to a delayed transaction upon the arrival of any upstream request, or when a deferred transaction is outstanding, or when downstream command queue space is unavailable. This prevents known deadlock conditions due to resource conflicts.
  • a PAM defines a section of address space in which a read and a write to two interfaces are both executed with a single atomic instruction. At least one of these interfaces is the memory interface, but the other can be one of the downstream command queues.
  • an initial locked read is addressed to PAM-controlled memory, it is possible that the corresponding locked write will be directed towards a downstream interface without available command or data queue space. Due to known dependency rules, this downstream command queue should remain unblocked and eventually drain to make room for the write request. This, however, can take a significant amount of time, all the while blocking other unrelated memory-bound transactions on the processor bus, thereby hurting overall system performance.
  • logic determines if sufficient downstream write data buffer space and sufficient downstream command buffer space is available for the locked write that is associated with an initial locked memory-bound read transaction that is potentially within programmable attribute map space. In one embodiment, two chunks of write data buffer space and two slots of command buffer space is considered sufficient. If both conditions are met, the read request can be accepted. Otherwise, the read transaction can become a delayed transaction. The delayed transaction can reserve the downstream queue so that it will drain to make room for the write transaction when it is reattempted.
  • potential PAM space rather than actual PAM space is detected. Since PAM space can be segmented into multiple disjointed areas, a single address space that encompasses all the possible PAM spaces simplifies the detection process, with minimal penalty for occasionally creating a delayed transaction when the target address was not within actual PAM space.
  • FIG. 6 shows a procedure that can be followed by this process.
  • a locked request to potential PAM space is initiated.
  • Step 610 checks to see if sufficient write data buffer space is available, while step 620 checks to see if sufficient command buffer space is available. If both are sufficient, the locked transaction is dispatched at step 630 , and subsequent processing continues normally. However, if there is insufficient write data buffer space or insufficient command buffer space available for the locked request, a delayed transaction response is issued at step 640 .
  • processing then continues normally for a delayed transaction.
  • the invention can be implemented in circuitry or as a method.
  • the invention can also include instructions stored on a machine-readable medium, which can be read and executed by at least one machine to perform the functions described herein.
  • a machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer, state machine or programmable logic).
  • a machine-readable medium can include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.), and others.

Abstract

A combination of techniques to prevent deadlocks and livelocks in a computer system having a dispatcher and multiple downstream command queues. In one embodiment, a broadcast transaction that requires simultaneously available space in all the affected downstream command queues becomes a delayed transaction, so that the command queues are reserved and other transactions are retried until the broadcast transaction is completed. In another embodiment, a bail-out timer is used to defer a transaction if the transaction does not complete within a predetermined time. In yet another embodiment, a locked transaction that potentially addresses memory space controlled by a programmable attribute map is handled as a delayed transaction if there is less than a predetermined amount of downstream buffer space available for the transaction.

Description

    BACKGROUND OF THE INVENTION
  • 1. Field of the Invention [0001]
  • The invention pertains generally to computer systems. In particular, it pertains to avoiding deadlocks and livelocks in the dispatching and execution of bus transactions. [0002]
  • 2. Description of the Related Art [0003]
  • In a continuing attempt to increase performance, many computer systems send bus transactions to a centralized input/output (I/O) controller, which uses multiple queues to dispatch each transaction to one of several different interfaces in the system, and which coordinates execution of various stages of the transaction. [0004]
  • FIG. 1 shows a portion of a conventional computer system containing such a centralized I/[0005] O controller 10, which controls the transfer of commands and data between processors 11, 12, graphics controller 13, memory controller 14, and peripheral bus controller 15. Each is connected to I/O controller 10 over a separate interface 21, 23, 24 and 25, respectively, each of which may be a bus.
  • FIG. 2 shows a more detailed view of I/[0006] O controller 10. A request from one of the CPU's 11, 12 to initiate a transaction is decoded by request decoder 111, which loads the request into In-Order Queue (IOQ) 112. IOQ 112 keeps the various phases of multiple transactions executing in the correct order, so that a given phase of a subsequent transaction will not be executed before the same phase of a preceding transaction. This is done by placing the request for the transaction into dispatch queue 113 and response queue 115, and for memory requests, into snoop queue 117 and snoop response queue 119. Although shown and discussed as four separate queues, these may actually be a single queue with four separate pointers indicating which location is considered to be the exit of the queue for each function.
  • When an indicator [0007] exits dispatch queue 113, it triggers dispatcher 114 to send the transaction to the correct interface 23, 24 or 25, through the associated command queue 130, 140, or 150, which queues up the transaction before it is presented to the respective interface. The transactions are “drained” from the command queues as the transactions are serviced by the receiving circuitry. When the target device responds, that response clears the associated request from the exit of response queue 115. If the request is to a memory system with cache, a snoop function and its response are also processed through queues 117, 119. Thus a transaction is completed only when the relevant request has been cleared from all queues in IOQ 112.
  • Memory transactions through [0008] queue 150 are typically guaranteed to complete within a specified time, and occupy processor bus 21 until the transaction is complete. However, transactions through downstream queues 130 and 140 (“downstream transactions”) have no guaranteed completion time, and time to complete can vary greatly. Since a target device may not always be ready to accept a command, alternative responses are available to prevent this condition from clogging up the queues. A retry response is a response from the I/O controller to the requestor that tells the requester to abort the request and try again later. This response clears that particular request from all queues in IOQ 112. When the request is retried at a later time, it enters IOQ 112 as a new request. A delayed transaction response includes a retry response, but the I/O controller 10 and the target interface also commit resources to the eventual retry, thus blocking those resources from other transactions and potentially forcing those other transactions to be reattempted. Only one transaction may be delayed at a time. A deferred response does not require a reattempt by the initiator—the I/O controller notifies the initiator that the target device will provide the requested data when it is ready, and the I/O controller will pass the data on to the initiator using a special transaction called a deferred reply. Although the transaction is complete when the request is deferred, the operation continues until the deferred reply, and various resources may remain committed until the deferred reply. In all these cases, the request is cleared from the queues in IOQ 112 when the retry/delay/defer status is created by the response from the I/O controller to the requester. A request can be initially assigned an identifier, so that if it is reattempted with the same identifier, all affected devices can correlate the reattempt with the original request.
  • The interactive nature of the various queues and associated resources can cause both deadlocks and livelocks to occur, based on conflicting resource dependencies. As applied to the queue structure, a deadlock occurs when the output of two or more queues cannot be cleared because the data to initiate a clearing action in each is blocked within the other queue. A livelock occurs when a requested transaction cannot make progress in one queue because it depends on another queue which, although moving, is always full and thereby repeatedly forcing some type of reattempt. In brief, a livelock creates an ongoing bottleneck in the system, which may eventually go away in normal operation after an unacceptably long time, while a deadlock causes a blockage in the system that will not go away without some type of overt corrective action. [0009]
  • Some deadlocks and livelocks are generic to a system and can be avoided through proper overall system design. Others are only seen during specific, unusual circumstances and must be addressed with a customized solution on a case-by-case basis. [0010]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 shows a system of the prior art. [0011]
  • FIG. 2 shows an I/O controller of the prior art. [0012]
  • FIG. 3 shows an I/O controller of the invention. [0013]
  • FIG. 4 shows a flow chart for handling a broadcast transaction. [0014]
  • FIG. 5 shows a flow chart for using a bail-out timer. [0015]
  • FIG. 6 shows a flow chart for handling a locked request to PAM space.[0016]
  • DETAILED DESCRIPTION OF THE INVENTION
  • One or more embodiments of the invention are directed to avoiding various types of deadlock/livelock situations through the use of delayed or deferred transactions. These embodiments are explained in more detail below. [0017]
  • End-of-Interrupt Broadcast Command [0018]
  • A broadcast command is a command that is recognized by all (or at least many) of the devices that receive it. A broadcast command allows a general-purpose command to be sent to all relevant devices without having to maintain a list of those devices, and without having to send individually-addressed messages to each device on the list. A broadcast command typically contains a destination address that is recognized by all intended target devices. Since a broadcast command may be seen and used by many devices, it is generally not feasible for the sender to determine if all relevant devices have responded, and in some embodiments no response at all is required. [0019]
  • An End-of-Interrupt command is a broadcast command that indicates the CPU has completed processing of an interrupt. It can be broadcast to all buses where an interrupt controller (i.e., a device that can generate an interrupt) might be attached. For proper execution, space for this command must be simultaneously available in all [0020] downstream command queues 130, 140 when the command is dispatched. If one or more downstream command queues is full or otherwise unavailable, it may not be feasible for the IOQ to hold this command while waiting for the downstream command queues to drain, since the IOQ itself may contain the request, or be blocking the CPU or upstream processor bus request, needed to initiate draining of the blocked downstream command queue, thus creating a deadlock. On the other hand, forcing a retry of the EOI command can create a livelock because other competing commands, such as those not requiring multiple simultaneous queue space availability, can repeatedly refill the downstream command queues before the EOI is reattempted.
  • FIGS. 3 and 4 illustrate one embodiment of the invention, which uses the delayed transaction mechanism to guarantee available resources for the EOI request. As shown in FIG. 3, each of [0021] queues 130, 140 provide an indicator back to dispatcher 114 when they are full so that dispatcher 114 will not dispatch a transaction into a queue that has no place to put it. If one or more downstream command queues is full, dispatcher 114 can hold the EOI transaction while waiting for the queues to drain, provided no other commands are pending. However, if any other CPU request is received, I/O controller 10 can use its internal logic to terminate the transaction by sending a delayed transaction response back to the requestor. A delayed transaction response is essentially a retry response, except the necessary resources are reserved for the eventual retry attempt. In this case, downstream command queue space is reserved. Therefore, other requests requiring one of the downstream command queues can themselves be directed to retry as long as the delayed transaction is pending. This prevents other requests from repeatedly filling the downstream command queues, and allows these queues to drain. In this case, ‘other requests’ also includes other EOI commands, which can be differentiated from the subject EOI command by their transaction identifiers.
  • Eventually, the subject EOI command will be reattempted while space is simultaneously available in all the downstream command queues. The EOI command can then execute successfully. Once it does, the delayed operation is complete and the other devices will no longer be forced to retry. [0022]
  • FIG. 4 shows a procedure that can be followed by this process. At [0023] step 400, a broadcast transaction is initiated by loading it into IOQ 112. When it reaches the exit of dispatch queue 113, dispatcher 114 determines at step 410 if any of the downstream command queues 130, 140 are full. If none are full, i.e., if there is space in all downstream command queues hold a transaction, the broadcast transaction is dispatched to the downstream command queues at step 420, and any subsequent transactions are also handled normally at step 430. However, if step 410 determines that at least one of the downstream command queues is full, the IOQ is checked at step 440 to see if any other requests are pending. If not, the system loops through steps 410 and 440 while waiting for the command queues to drain so the broadcast transaction can be dispatched. If another request is detected in the IOQ, either before or during this looping operation, a delayed transaction response is issued to the requestor at step 450. The downstream command queues are now reserved for the eventual reattempt of the broadcast transaction, and any other transactions that subsequently reach dispatcher 114 and require one of the downstream command queues 130, 140 can be given a retry response at step 460 to prevent them from filling up the command queues At step 470, the broadcast transaction is eventually retried. As before, if all command queues have space, the retried broadcast transaction is dispatched and any subsequent transactions are then handled normally. If at least one of the downstream command queues is still full, the delayed transaction cycle repeats until all queues have space to accept the broadcast command.
  • Deferrable Transaction Bail-Out Timer [0024]
  • A deadlock can also occur when the IOQ depth is configured to 1 (meaning each of [0025] queues 113, 115, 117 and 119 can only contain one entry—in certain situations this is desirable), and a non-postable downstream transaction's completion is blocked by a downstream agent's need to access main memory via processor bus 21. A non-postable transaction is a transaction that must wait for a response, so IOQ 112 must wait for a response before permitting any other transactions to proceed. The non-postable transaction cannot be deferred because the I/O controller's conventional defer policy requires that another request be present in the IOQ before it defers the current request at the outlet of the dispatch queue. Since another request cannot arrive when the IOQ is set to 1, this condition for deferral will never be true.
  • The invention can use a timer to handle this situation. [0026] Timer 315 in FIG. 3 starts counting whenever a deferrable request is dispatched. Deferrable transactions can include, for example, non-locked CPU-to-peripheral reads and CPU-to-peripheral I/O type writes. If the transaction is completed (i.e., the response is received from the destination device) before the timer expires, the timer can be disabled, as it is no longer needed. However, if the timer expires before a response is received from the destination device, the transaction can be unconditionally deferred, thus “bailing out” of the original transaction. The expiration time on the timer can be programmable, and the timer may be enabled and disabled via configuration programming. This approach has the advantage of initiating the deferred state only if it is potentially needed to resolve a deadlock or livelock. If the transaction executes in a reasonable time, the timer never expires and the transaction is never deferred. Since deferral creates delays in execution, this process avoids unnecessary delays. On the other hand, if the transaction does not execute in a reasonable time, then a deadlock or livelock situation is likely, and the deferral acts to break the deadlock/livelock. While the above description assumes an IOQ depth of 1, the bail-out timer can also be used when the IOQ depth is greater than 1 for the purpose of avoiding other deadlock or livelock conditions.
  • FIG. 5 shows a procedure that can be followed by this process. When a deferrable transaction is dispatched at [0027] step 500, the bail-out timer is started at step 510. The system will then loop through steps 520 and 530 while waiting for a response to be received or the timer to expire. If a response is received at step 520 before the timer expires, the timer is stopped at step 550 and processing continues normally at step 560. However, it the timer expires at step 530 before the response is received, a deferred response is issued to the requestor at step 540, whereupon the timer is stopped and processing continues normally for a deferred transaction.
  • Delayed Transaction of Initial Locked Reads due to Write Data buffer Unavailability [0028]
  • A “locked” command is one that locks up the required resources, making them unavailable to other transactions, until a given sequence of commands completes. For example, a locked request from a CPU to a peripheral controller might lock up [0029] processor bus 21, peripheral downstream command queue 150, peripheral bus 25, and the peripheral controller, thus preventing other devices from using those resources until the locked command has completed and the resources are unlocked. In a conventional system, an initial locked read is converted to a delayed transaction upon the arrival of any upstream request, or when a deferred transaction is outstanding, or when downstream command queue space is unavailable. This prevents known deadlock conditions due to resource conflicts. However, it does not address a situation in which a locked sequence addresses the region of memory controlled by the programmable attribute map (PAM), in which a read and a write may be directed to two different command queues. A PAM defines a section of address space in which a read and a write to two interfaces are both executed with a single atomic instruction. At least one of these interfaces is the memory interface, but the other can be one of the downstream command queues. Under these conditions, if an initial locked read is addressed to PAM-controlled memory, it is possible that the corresponding locked write will be directed towards a downstream interface without available command or data queue space. Due to known dependency rules, this downstream command queue should remain unblocked and eventually drain to make room for the write request. This, however, can take a significant amount of time, all the while blocking other unrelated memory-bound transactions on the processor bus, thereby hurting overall system performance.
  • In one embodiment, logic determines if sufficient downstream write data buffer space and sufficient downstream command buffer space is available for the locked write that is associated with an initial locked memory-bound read transaction that is potentially within programmable attribute map space. In one embodiment, two chunks of write data buffer space and two slots of command buffer space is considered sufficient. If both conditions are met, the read request can be accepted. Otherwise, the read transaction can become a delayed transaction. The delayed transaction can reserve the downstream queue so that it will drain to make room for the write transaction when it is reattempted. [0030]
  • In one embodiment, potential PAM space rather than actual PAM space is detected. Since PAM space can be segmented into multiple disjointed areas, a single address space that encompasses all the possible PAM spaces simplifies the detection process, with minimal penalty for occasionally creating a delayed transaction when the target address was not within actual PAM space. [0031]
  • FIG. 6 shows a procedure that can be followed by this process. At [0032] step 600, a locked request to potential PAM space is initiated. Step 610 checks to see if sufficient write data buffer space is available, while step 620 checks to see if sufficient command buffer space is available. If both are sufficient, the locked transaction is dispatched at step 630, and subsequent processing continues normally. However, if there is insufficient write data buffer space or insufficient command buffer space available for the locked request, a delayed transaction response is issued at step 640. At step 650, processing then continues normally for a delayed transaction.
  • The embodiments involving broadcast commands, a bail-out timer, and locked reads to PAM space can be implemented individually or in any combination. [0033]
  • The invention can be implemented in circuitry or as a method. The invention can also include instructions stored on a machine-readable medium, which can be read and executed by at least one machine to perform the functions described herein. A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer, state machine or programmable logic). For example, a machine-readable medium can include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.), and others. [0034]
  • The foregoing description is intended to be illustrative and not limiting. Variations will occur to those of skill in the art. Those variations are intended to be included in the invention, which is limited only by the spirit and scope of the appended claims. [0035]

Claims (30)

We claim:
1. A method, comprising:
receiving a broadcast transaction from a requestor in a computer system;
determining if a command queue is full;
dispatching the broadcast transaction to the command queue if the command queue is not full; and
issuing a delay transaction response to the requestor if the command queue is full.
2. The method of claim 1, wherein the broadcast transaction is an End-of-Interrupt transaction.
3. The method of claim 1, further comprising:
forcing other transactions to retry if the delay transaction response was issued;
receiving a retry of the broadcast transaction from the requestor if the delay transaction response was issued; and
dispatching the retried broadcast command to the command queue if the command queue is not full.
4. An apparatus, comprising:
a command queue coupled to a detector to detect if the command queue is full;
a command dispatcher coupled to the command queue and the detector, the command dispatcher including:
logic to dispatch a broadcast command from a requestor to the command queue if the command queue is not full; and
logic to respond to the requestor with a delay transaction response if the command queue is full.
5. The apparatus of claim 4, wherein the broadcast command is an End-of-Interrupt transaction.
6. The apparatus of claim 4, further including logic to force a retry of subsequent commands until a retried broadcast command has been dispatched to the command queue.
7. A machine-readable medium having stored thereon instructions, which when executed by at least one machine cause said at least one machine to perform:
receiving a broadcast transaction from a requestor in a computer system;
determining if a command queue is full;
dispatching the broadcast transaction to the command queue if the command queue is not full; and
issuing a delay transaction response to the requester if the command queue is full.
8. The medium of claim 7, wherein the broadcast transaction is an End-of-Interrupt transaction.
9. The medium of claim 7, further comprising:
forcing other transactions to retry if the delay transaction response was issued;
receiving a retry of the broadcast transaction from the requestor if the delay transaction response was issued; and
dispatching the retried broadcast command to the command queue if the command queue is not full.
10. A method, comprising:
dispatching a bus transaction from a requestor to a device;
starting a timer;
determining if the timer expires before the device responds to the dispatched bus transaction; and
issuing a deferred transaction response to the requestor if the timer expires.
11. The method of claim 10, wherein starting occurs only if an in-order-queue has a depth of 1.
12. The method of claim 10, wherein issuing includes issuing an unconditionally deferred transaction.
13. An apparatus, comprising:
a command dispatcher coupled to a command queue;
a detector coupled to the command dispatcher to detect if a command dispatched to the command queue by the command dispatcher has been responded to;
a timer coupled to the detector; and
logic coupled to the timer to issue a deferred response to the requestor if the timer expires before the command has been responded to.
14. The apparatus of claim 13, wherein the logic includes logic to issue the deferred response if an in-order-queue has a depth of 1.
15. The apparatus of claim 13, wherein the timer is a programmable timer.
16. A machine-readable medium having stored thereon instructions, which when executed by at least one machine cause said at least one machine to perform:
receiving a bus transaction from a requestor to a device;
starting a timer;
determining if the timer expires before the device responds to the dispatched bus transaction; and
issuing a deferred transaction response to the requestor if the timer expires.
17. The medium of claim 16, wherein starting occurs only if an in-order-queue has a depth of 1.
18. The medium of claim 16, wherein issuing includes issuing an unconditionally deferred transaction.
19. A method, comprising;
determining if write data buffer space and command buffer space are available for an initial locked memory read transaction that is potentially within programmable attribute map space;
dispatching the read transaction if the write data buffer space and command buffer space are available; and
issuing a delayed transaction response if the write data buffer space and command buffer space are not available.
20. The method of claim 19, wherein determining includes determining if the write data buffer space and command buffer space are available in a downstream queue.
21. The method of claim 20, wherein dispatching includes dispatching to the downstream queue.
22. An apparatus, comprising:
a command dispatcher coupled to a destination queue;
a detector coupled to the destination queue to detect if the write data buffer space and command buffer space are available for use by an initial locked memory read transaction that is potentially within programmable attribute map space;
logic coupled to the command dispatcher to dispatch the read transaction if the write data buffer space and command buffer space are available; and
logic coupled to the command dispatcher to convert the transaction to a delayed transaction if the write data buffer space and command buffer space are not available.
23. The apparatus of claim 22, wherein the destination queue is a downstream queue.
24. The apparatus of claim 22, wherein the command dispatcher includes an in-order queue.
25. A machine-readable medium having stored thereon instructions, which when executed by at least one machine cause said at least one machine to perform:
determining if write data buffer space and command buffer space are available for an initial locked memory read transaction that is potentially within programmable attribute map space;
dispatching the read transaction if the write data buffer space and command buffer space are available; and
issuing a delayed transaction response if the write data buffer space and command buffer space are not available.
26. The medium of claim 25, wherein determining includes determining if the write data buffer space and command buffer space are available in a downstream queue.
27. The medium of claim 26, wherein dispatching includes dispatching to the downstream queue.
28. A system, comprising:
a command dispatcher coupled to a command queue;
broadcast command control logic having:
a first detector coupled to the command queue and the command dispatcher to detect if the command queue is full;
first logic coupled to the first detector to dispatch a broadcast command from the command dispatcher to the command queue if the command queue is not full; and
second logic coupled to the first detector to respond to the requestor with a first delayed transaction response if the command queue is full;
dispatch timer logic having:
a second detector coupled to the command dispatcher to detect if a first command dispatched to the command queue by the command dispatcher has been responded to;
a timer coupled to the second detector; and
third logic coupled to the timer to issue a deferred response to the requestor if the timer expires before the first command has been responded to; and
lock read control logic having:
a third detector coupled to the command queue to detect if write data buffer space and command buffer space are available for use by an initial locked memory read transaction that is potentially within programmable attribute map space;
fourth logic coupled to the command dispatcher to dispatch the read transaction if the write data buffer space and command buffer space are available; and
fifth logic coupled to the command dispatcher to issue a second delayed transaction response to the requestor if the write data buffer space and command buffer space are not available.
29. The system of claim 28, wherein the broadcast command is an End-of-Interrupt transaction.
30. The system of claim 28, wherein the timer is a programmable timer.
US10/674,316 2000-09-11 2003-09-29 Managing bus transaction dependencies Abandoned US20040078507A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/674,316 US20040078507A1 (en) 2000-09-11 2003-09-29 Managing bus transaction dependencies

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/659,108 US6694390B1 (en) 2000-09-11 2000-09-11 Managing bus transaction dependencies
US10/674,316 US20040078507A1 (en) 2000-09-11 2003-09-29 Managing bus transaction dependencies

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US09/659,108 Division US6694390B1 (en) 2000-09-11 2000-09-11 Managing bus transaction dependencies

Publications (1)

Publication Number Publication Date
US20040078507A1 true US20040078507A1 (en) 2004-04-22

Family

ID=31188882

Family Applications (3)

Application Number Title Priority Date Filing Date
US09/659,108 Expired - Fee Related US6694390B1 (en) 2000-09-11 2000-09-11 Managing bus transaction dependencies
US10/674,944 Expired - Fee Related US7082480B2 (en) 2000-09-11 2003-09-29 Managing bus transaction dependencies
US10/674,316 Abandoned US20040078507A1 (en) 2000-09-11 2003-09-29 Managing bus transaction dependencies

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US09/659,108 Expired - Fee Related US6694390B1 (en) 2000-09-11 2000-09-11 Managing bus transaction dependencies
US10/674,944 Expired - Fee Related US7082480B2 (en) 2000-09-11 2003-09-29 Managing bus transaction dependencies

Country Status (1)

Country Link
US (3) US6694390B1 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060230205A1 (en) * 2005-04-06 2006-10-12 Toshiba America Electronic Components Back-off timing mechanism
US7177853B1 (en) * 2002-02-21 2007-02-13 Emc Corporation Cache management via statistically adjusted time stamp queue
US20070198751A1 (en) * 2006-02-03 2007-08-23 International Business Machines Corporation Method and apparatus for managing dependencies between split transaction queues
US20090070507A1 (en) * 2007-09-12 2009-03-12 Shigehiro Asano Back-Off Timing Mechanism

Families Citing this family (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6694390B1 (en) * 2000-09-11 2004-02-17 Intel Corporation Managing bus transaction dependencies
GB0028353D0 (en) * 2000-11-21 2001-01-03 Aspex Technology Ltd Improvements relating to digital data communications
DE10255937B4 (en) * 2002-11-29 2005-03-17 Advanced Micro Devices, Inc., Sunnyvale Order-controlled command storage
US7496726B1 (en) * 2005-04-18 2009-02-24 Sun Microsystems, Inc. Controlling contention via transactional timers among conflicting transactions issued by processors operating in insistent or polite mode
TWI311705B (en) * 2005-05-23 2009-07-01 Via Tech Inc Peripheral component interconnect express and changing method of link power states thereof
JP4555791B2 (en) * 2006-03-16 2010-10-06 富士通株式会社 Data reading method and data reading apparatus
US7502873B2 (en) * 2006-10-10 2009-03-10 International Business Machines Corporation Facilitating access to status and measurement data associated with input/output processing
US7500023B2 (en) * 2006-10-10 2009-03-03 International Business Machines Corporation Facilitating input/output processing by using transport control words to reduce input/output communications
US20090054092A1 (en) * 2007-08-20 2009-02-26 Anthony Pierre Stonefield Interactive Interface for Devices Supporting Communication Employing Sender-Specified Media Content
US7899944B2 (en) * 2008-02-14 2011-03-01 International Business Machines Corporation Open exchange limiting in an I/O processing system
US9052837B2 (en) 2008-02-14 2015-06-09 International Business Machines Corporation Processing communication data in a ships passing condition
US8312189B2 (en) * 2008-02-14 2012-11-13 International Business Machines Corporation Processing of data to monitor input/output operations
US7908403B2 (en) * 2008-02-14 2011-03-15 International Business Machines Corporation Reserved device access contention reduction
US8082481B2 (en) * 2008-02-14 2011-12-20 International Business Machines Corporation Multiple CRC insertion in an output data stream
US7904605B2 (en) * 2008-02-14 2011-03-08 International Business Machines Corporation Computer command and response for determining the state of an I/O operation
US8095847B2 (en) * 2008-02-14 2012-01-10 International Business Machines Corporation Exception condition handling at a channel subsystem in an I/O processing system
US8166206B2 (en) * 2008-02-14 2012-04-24 International Business Machines Corporation Cancel instruction and command for determining the state of an I/O operation
US8108570B2 (en) * 2008-02-14 2012-01-31 International Business Machines Corporation Determining the state of an I/O operation
US8117347B2 (en) 2008-02-14 2012-02-14 International Business Machines Corporation Providing indirect data addressing for a control block at a channel subsystem of an I/O processing system
US7941570B2 (en) * 2008-02-14 2011-05-10 International Business Machines Corporation Bi-directional data transfer within a single I/O operation
US7917813B2 (en) * 2008-02-14 2011-03-29 International Business Machines Corporation Exception condition determination at a control unit in an I/O processing system
US8001298B2 (en) 2008-02-14 2011-08-16 International Business Machines Corporation Providing extended measurement data in an I/O processing system
US8196149B2 (en) * 2008-02-14 2012-06-05 International Business Machines Corporation Processing of data to determine compatability in an input/output processing system
US7937507B2 (en) * 2008-02-14 2011-05-03 International Business Machines Corporation Extended measurement word determination at a channel subsystem of an I/O processing system
US7840717B2 (en) * 2008-02-14 2010-11-23 International Business Machines Corporation Processing a variable length device command word at a control unit in an I/O processing system
US8176222B2 (en) * 2008-02-14 2012-05-08 International Business Machines Corporation Early termination of an I/O operation in an I/O processing system
US8478915B2 (en) 2008-02-14 2013-07-02 International Business Machines Corporation Determining extended capability of a channel path
US8214562B2 (en) * 2008-02-14 2012-07-03 International Business Machines Corporation Processing of data to perform system changes in an input/output processing system
US7890668B2 (en) 2008-02-14 2011-02-15 International Business Machines Corporation Providing indirect data addressing in an input/output processing system where the indirect data address list is non-contiguous
US7840718B2 (en) * 2008-02-14 2010-11-23 International Business Machines Corporation Processing of data to suspend operations in an input/output processing log-out system
US7904606B2 (en) * 2008-07-31 2011-03-08 International Business Machines Corporation Transport control channel program chain linked branching
US7937504B2 (en) * 2008-07-31 2011-05-03 International Business Machines Corporation Transport control channel program message pairing
US8055807B2 (en) 2008-07-31 2011-11-08 International Business Machines Corporation Transport control channel program chain linking including determining sequence order
US8332542B2 (en) 2009-11-12 2012-12-11 International Business Machines Corporation Communication with input/output system devices
EP2444903A1 (en) 2010-09-29 2012-04-25 STMicroelectronics (Grenoble 2) SAS A transaction reordering arrangement
US9021155B2 (en) 2011-06-01 2015-04-28 International Business Machines Corporation Fibre channel input/output data routing including discarding of data transfer requests in response to error detection
US8364853B2 (en) 2011-06-01 2013-01-29 International Business Machines Corporation Fibre channel input/output data routing system and method
US8364854B2 (en) 2011-06-01 2013-01-29 International Business Machines Corporation Fibre channel input/output data routing system and method
US8583988B2 (en) 2011-06-01 2013-11-12 International Business Machines Corporation Fibre channel input/output data routing system and method
US8677027B2 (en) 2011-06-01 2014-03-18 International Business Machines Corporation Fibre channel input/output data routing system and method
US8738811B2 (en) 2011-06-01 2014-05-27 International Business Machines Corporation Fibre channel input/output data routing system and method
US8312176B1 (en) 2011-06-30 2012-11-13 International Business Machines Corporation Facilitating transport mode input/output operations between a channel subsystem and input/output devices
US8473641B2 (en) 2011-06-30 2013-06-25 International Business Machines Corporation Facilitating transport mode input/output operations between a channel subsystem and input/output devices
US8549185B2 (en) 2011-06-30 2013-10-01 International Business Machines Corporation Facilitating transport mode input/output operations between a channel subsystem and input/output devices
US8346978B1 (en) 2011-06-30 2013-01-01 International Business Machines Corporation Facilitating transport mode input/output operations between a channel subsystem and input/output devices
JP5805546B2 (en) * 2012-01-13 2015-11-04 ルネサスエレクトロニクス株式会社 Semiconductor device
US8943504B2 (en) * 2012-04-20 2015-01-27 Qualcomm Incorporated Tracking and releasing resources placed on a deferred unlock list at the end of a transaction
ITTO20120470A1 (en) 2012-05-30 2013-12-01 St Microelectronics Srl PROCEDURE FOR MANAGING ACCESS AND RELATIONSHIP SYSTEM TRANSACTIONS
JP5987498B2 (en) * 2012-06-27 2016-09-07 富士通株式会社 Storage virtualization apparatus, storage virtualization method, and storage virtualization program
US8918542B2 (en) 2013-03-15 2014-12-23 International Business Machines Corporation Facilitating transport mode data transfer between a channel subsystem and input/output devices
US8990439B2 (en) 2013-05-29 2015-03-24 International Business Machines Corporation Transport mode data transfer between a channel subsystem and input/output devices
US10310923B1 (en) 2014-08-28 2019-06-04 Seagate Technology Llc Probabilistic aging command sorting
US10831403B2 (en) 2017-05-19 2020-11-10 Seagate Technology Llc Probabalistic command aging and selection
TWI692721B (en) * 2018-11-02 2020-05-01 大陸商深圳大心電子科技有限公司 Command processing method and storage controller using the same
US11500589B2 (en) * 2020-10-05 2022-11-15 Western Digital Technologies, Inc. Command draining using host memory buffer
US11861217B2 (en) * 2020-10-05 2024-01-02 Western Digital Technologies, Inc. DRAM-less SSD with command draining
US11909643B2 (en) 2021-09-13 2024-02-20 Hewlett Packard Enterprise Development Lp Efficient progression management in a tracker with multiple sources

Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5006982A (en) * 1988-10-21 1991-04-09 Siemens Ak. Method of increasing the bandwidth of a packet bus by reordering reply packets
US5467295A (en) * 1992-04-30 1995-11-14 Intel Corporation Bus arbitration with master unit controlling bus and locking a slave unit that can relinquish bus for other masters while maintaining lock on slave unit
US5493566A (en) * 1992-12-15 1996-02-20 Telefonaktiebolaget L M. Ericsson Flow control system for packet switches
US5682551A (en) * 1993-03-02 1997-10-28 Digital Equipment Corporation System for checking the acceptance of I/O request to an interface using software visible instruction which provides a status signal and performs operations in response thereto
US5761444A (en) * 1995-09-05 1998-06-02 Intel Corporation Method and apparatus for dynamically deferring transactions
US5930485A (en) * 1997-01-07 1999-07-27 Apple Computer, Inc. Deadlock avoidance in a computer system having unordered slaves
US5948094A (en) * 1995-09-29 1999-09-07 Intel Corporation Method and apparatus for executing multiple transactions within a single arbitration cycle
US6021483A (en) * 1997-03-17 2000-02-01 International Business Machines Corporation PCI-to-PCI bridges with a timer register for storing a delayed transaction latency
US6065089A (en) * 1998-06-25 2000-05-16 Lsi Logic Corporation Method and apparatus for coalescing I/O interrupts that efficiently balances performance and latency
US6108735A (en) * 1995-09-29 2000-08-22 Intel Corporation Method and apparatus for responding to unclaimed bus transactions
US6145302A (en) * 1997-08-20 2000-11-14 Siemens Aktiengesellschaft Method for monitoring a catalytic converter
US6694390B1 (en) * 2000-09-11 2004-02-17 Intel Corporation Managing bus transaction dependencies
US6728808B1 (en) * 2000-02-07 2004-04-27 3Com Corporation Mechanism for optimizing transaction retries within a system utilizing a PCI bus architecture

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6145032A (en) * 1998-09-21 2000-11-07 International Business Machines Corporation System for recirculation of communication transactions in data processing in the event of communication stall

Patent Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5006982A (en) * 1988-10-21 1991-04-09 Siemens Ak. Method of increasing the bandwidth of a packet bus by reordering reply packets
US5467295A (en) * 1992-04-30 1995-11-14 Intel Corporation Bus arbitration with master unit controlling bus and locking a slave unit that can relinquish bus for other masters while maintaining lock on slave unit
US5887194A (en) * 1992-04-30 1999-03-23 Intel Corporation Locking protocol for peripheral component interconnect utilizing master device maintaining assertion of lock signal after relinquishing control of bus such that slave device remains locked
US5493566A (en) * 1992-12-15 1996-02-20 Telefonaktiebolaget L M. Ericsson Flow control system for packet switches
US5682551A (en) * 1993-03-02 1997-10-28 Digital Equipment Corporation System for checking the acceptance of I/O request to an interface using software visible instruction which provides a status signal and performs operations in response thereto
US5761444A (en) * 1995-09-05 1998-06-02 Intel Corporation Method and apparatus for dynamically deferring transactions
US6108735A (en) * 1995-09-29 2000-08-22 Intel Corporation Method and apparatus for responding to unclaimed bus transactions
US5948094A (en) * 1995-09-29 1999-09-07 Intel Corporation Method and apparatus for executing multiple transactions within a single arbitration cycle
US5930485A (en) * 1997-01-07 1999-07-27 Apple Computer, Inc. Deadlock avoidance in a computer system having unordered slaves
US6021483A (en) * 1997-03-17 2000-02-01 International Business Machines Corporation PCI-to-PCI bridges with a timer register for storing a delayed transaction latency
US6145302A (en) * 1997-08-20 2000-11-14 Siemens Aktiengesellschaft Method for monitoring a catalytic converter
US6065089A (en) * 1998-06-25 2000-05-16 Lsi Logic Corporation Method and apparatus for coalescing I/O interrupts that efficiently balances performance and latency
US6728808B1 (en) * 2000-02-07 2004-04-27 3Com Corporation Mechanism for optimizing transaction retries within a system utilizing a PCI bus architecture
US6694390B1 (en) * 2000-09-11 2004-02-17 Intel Corporation Managing bus transaction dependencies

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7177853B1 (en) * 2002-02-21 2007-02-13 Emc Corporation Cache management via statistically adjusted time stamp queue
US20060230205A1 (en) * 2005-04-06 2006-10-12 Toshiba America Electronic Components Back-off timing mechanism
US7290074B2 (en) * 2005-04-06 2007-10-30 Kabushiki Kaisha Toshiba Back-off timing mechanism
US20070198751A1 (en) * 2006-02-03 2007-08-23 International Business Machines Corporation Method and apparatus for managing dependencies between split transaction queues
US7487267B2 (en) * 2006-02-03 2009-02-03 International Business Machines Corporation Method and apparatus for managing dependencies between split transaction queues
US20090070507A1 (en) * 2007-09-12 2009-03-12 Shigehiro Asano Back-Off Timing Mechanism
US7613859B2 (en) 2007-09-12 2009-11-03 Kabushiki Kaisha Toshiba Back-off timing mechanism in a digital signal processor

Also Published As

Publication number Publication date
US20040059839A1 (en) 2004-03-25
US6694390B1 (en) 2004-02-17
US7082480B2 (en) 2006-07-25

Similar Documents

Publication Publication Date Title
US6694390B1 (en) Managing bus transaction dependencies
EP0618532B1 (en) Deadlock detecting device
US6292860B1 (en) Method for preventing deadlock by suspending operation of processors, bridges, and devices
US5590334A (en) Object oriented message passing system and method
US5448732A (en) Multiprocessor system and process synchronization method therefor
US6141715A (en) Method and system for avoiding live lock conditions on a computer bus by insuring that the first retired bus master is the first to resubmit its retried transaction
US5742830A (en) Method and apparatus for performing conditional operations on externally shared data
US5901295A (en) Address and data bus arbiter for pipelined transactions on a split bus
US6792497B1 (en) System and method for hardware assisted spinlock
US5758166A (en) Method and apparatus for selectively receiving write data within a write buffer of a host bridge
WO2002088936A1 (en) Multiprocessor communication system and method
US8914800B2 (en) Behavioral model based multi-threaded architecture
JPH1196124A (en) Parallel processor system
US20110126208A1 (en) Processing Architecture Having Passive Threads and Active Semaphores
EP0196331A1 (en) Method of and arrangement for ordering of multiprocessor operations in a multiprocessor system.
WO2003010667A1 (en) Resource locking and thread synchronization in a multiprocessor environment
US4979099A (en) Quasi-fair arbitration scheme with default owner speedup
EP1163581B1 (en) Monitor conversion in a multi-threaded computer system
EP1187029B1 (en) Peripheral component interconnect arbiter implementation with dynamic priority scheme
US20090172675A1 (en) Re-Entrant Atomic Signaling
JPH1049388A (en) Input and output controller
JP2804478B2 (en) Task control system and online transaction system
US7167939B2 (en) Asynchronous system bus adapter for a computer system having a hierarchical bus structure
US6857036B2 (en) Hardware method for implementing atomic semaphore operations using code macros
US5815676A (en) Address bus arbiter for pipelined transactions on a split bus

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION