[go: up one dir, main page]

EP2362955A1 - Prioritization for conflict arbitration in transactional memory management - Google Patents

Prioritization for conflict arbitration in transactional memory management

Info

Publication number
EP2362955A1
EP2362955A1 EP09799620A EP09799620A EP2362955A1 EP 2362955 A1 EP2362955 A1 EP 2362955A1 EP 09799620 A EP09799620 A EP 09799620A EP 09799620 A EP09799620 A EP 09799620A EP 2362955 A1 EP2362955 A1 EP 2362955A1
Authority
EP
European Patent Office
Prior art keywords
transactions
priority
conflict arbitration
conflict
priority values
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.)
Withdrawn
Application number
EP09799620A
Other languages
German (de)
French (fr)
Inventor
Charles Hall
Robert James Blainey
Mark Francis Wilding
Thomas Heller, Jr.
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.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of EP2362955A1 publication Critical patent/EP2362955A1/en
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/16—Handling requests for interconnection or transfer for access to memory bus
    • G06F13/1605—Handling requests for interconnection or transfer for access to memory bus based on arbitration
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/466—Transaction processing
    • G06F9/467—Transactional memory
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G06F9/526—Mutual exclusion algorithms

Definitions

  • the present invention relates to the field of transactional memory utilization in parallel computing and more particularly to conflict arbitration in transactional memory management.
  • Transactional memory techniques attempt to simplify parallel programming by allowing a group of load and store instructions to execute in an atomic way.
  • transactional memory is a concurrency control mechanism analogous to database transactions for controlling access to shared memory in concurrent computing.
  • transactional memory can be viewed as optimistic in that a thread completes modifications to shared memory without regard for the activities of other threads, while recording every performed read and write and buffering the speculative changes to memory.
  • Transactions conflict when two or more transactions access the same block of memory, and at least one of those accesses is a write access.
  • transactional memory instead of placing the onus on the reader or writer of a block of memory to ensure that the execution of a transaction does not conflict with other transactions in progress, the onus is placed on the transactional memory system to verify that other threads have not concurrently made conflicting references to the block of memory.
  • Such a transactional memory system can be realized in software, hardware, or a combination of the two.
  • the operation in which memory references are checked against other concurrent memory references is often referred to as validation. If validation is successful, at the conclusion of a transaction all memory changes are made permanent in an operation often referred to as a commit.
  • a transaction can abort at any time, causing all of prior changes performed by the transaction to be rolled back or undone. If a transaction cannot be committed due to conflicting changes, the transaction can be aborted and re-executed from the beginning until the transaction succeeds.
  • Conflict arbitration is the mechanism for deciding which transactions will be blocked or aborted when a conflict occurs, and which transactions will be allowed to continue execution.
  • Conflict arbitration is controlled by an underlying contention management policy.
  • Simple conflict arbitration mechanisms have been proposed for transactional memory systems, such as aborting a transaction when the transaction attempts to access data conflicting with an access of the same data by another active transaction. More recent research, however, has indicated the importance of better contention management. Better contention management avoids "livelock" that becomes possible in simple contention management policies, and better contention management can substantially improve performance in the case of frequent conflicts.
  • a sophisticated contention management policy can combine the temporary blocking of a transaction attempting a conflicting access while awaiting a successful commit by a competing transaction, with heuristics to maximize transaction throughput, and also with mechanisms to improve fairness or provide better guarantees of forward progress. Even still, while some contention management policies demonstrate good performance across a set of benchmarks or applications, no single policy has been found that is universally optimal.
  • Embodiments of the present invention address deficiencies of the art in respect to conflict arbitration for transactional memory systems and provide a novel and non-obvious method, system and computer program product for software prioritization of concurrent transactions for embedded conflict arbitration in transactional memory management.
  • a method for software prioritization of concurrent transactions for embedded conflict arbitration in transactional memory management can include setting different hardware registers with different priority values for correspondingly different transactions in a system configured for transactional memory management according to respective priority values specified by priority assignment logic in external software support for the system.
  • the method also can include detecting a conflict amongst the transactions in the system.
  • the method can include applying conflict arbitration within the system based upon the priority values specified by the priority assignment logic in the external software support for the system. Priorities values form the basis of the conflict arbitration mechanism and implement a contention management policy. Having software control the priority values allows for the use of different contention management policies as appropriate for each benchmark or application.
  • the method also can include retrieving a conflict arbitration control value from another register in the system.
  • the conflict arbitration control value can specify at least one of a type and a nature of a conflict arbitration action.
  • the application of the conflict arbitration can be limited to at least one of a type and a nature of a conflict arbitration action specified by the conflict arbitration control value.
  • the different priority values can be limited to a range of priority values able to be specified by the priority assignment logic in the external software support for the system.
  • applying conflict arbitration within the system based upon the priority values specified by the priority assignment logic in the external software support for the system can include blocking a selected one of the transactions having a lower priority than others of the transactions.
  • applying conflict arbitration within the system based upon the priority values specified by the priority assignment logic in the external software support for the system can include aborting a selected one of the transactions having a lower priority than others of the transactions.
  • applying conflict arbitration within the system based upon the priority values specified by the priority assignment logic in the external software support for the system can include detecting at least two of the transactions with equal priorities and generating an interrupt to the external software support to perform conflict arbitration for the at least two of the transactions in lieu of the system performing the conflict arbitration.
  • a multiprocessor computer data processing system can be provided.
  • the system can include multiple different processors coupled to memory in hardware and a transaction manager supported by an instruction set architecture (ISA) for each of the processors.
  • ISA instruction set architecture
  • the system also can include registers disposed in each of the processors.
  • the registers can store priority values for transactions accessing memory managed by the transaction manager.
  • Conflict arbitration logic also can be disposed in the system.
  • the logic can include hardware or software enabled to apply conflict arbitration to conflicting ones of the transactions according to the priority values corresponding to the conflicting ones of the transactions.
  • the system can include software support coupled to the hardware and configured to access the registers to set the priority values.
  • Figure 1 is a pictorial illustration of a process for software prioritization of concurrent transactions for embedded conflict arbitration in transactional memory management
  • Figure 2 is a schematic illustration of a multiprocessor computing system configured for software prioritization of concurrent transactions for embedded conflict arbitration in transactional memory management;
  • Figure 3 is a flow chart illustrating a process for software prioritization of concurrent transactions for embedded conflict arbitration in transactional memory management.
  • Embodiments of the present invention provide a method, system and computer program product for software prioritization of concurrent transactions for embedded conflict arbitration in transactional memory management.
  • a multiprocessor computing system can be configured for transactional memory management.
  • Each processor in the system can include externally accessible registers storing priority values for corresponding transactions executed by the processor.
  • Conflict arbitration logic is provided in the transactional memory system and arbitrates conflicted transactions according to externally established priority values stored in the registers corresponding to the conflicted transactions as directed by program code external to the processor. In this way, the conflict arbitration logic of the system can arbitrate conflicts for conflicted transactions without regard to the algorithm establishing the priority values.
  • Figure 1 is a pictorial illustration of a process for software prioritization of concurrent transactions for embedded conflict arbitration in transactional memory management.
  • multiprocessor hardware HOA can combine with software support HOB such as a multiprocessor configured operating system to provide a multiprocessor computing system.
  • the multiprocessor hardware 11OA can implement an
  • ISA and semantics 130 configured for transactional memory 140 across multiple different processors.
  • different processors can perform read and write transactions 150 on the transactional memory 140.
  • a priority 160 can be associated with each of the transactions 150.
  • the priority 160 while stored in the multiprocessor hardware 11OA, for example in internal registers, can be accessed and set by external priority assignment logic 120 provided by software support HOB.
  • the external priority assignment logic 120 when granted only non-privileged access to the internal registers storing the priority 160 can be limited to assigning a priority within a range of priority values.
  • the external priority assignment logic 120 when granted privileged access to the internal registers storing the priority 160, can assign priority values above or below the default range of values.
  • the priority 160 can be dependent upon how long a transaction has been running and can be a function of the time accounting for when the transaction first started, with an earlier start time being assigned a higher priority value.
  • the original start time of the transaction in response to an abort and restart condition, can be reused to set the priority so that the assigned priority is the same as when the transaction was first attempted.
  • Such a timestamp- based approach can be desirable to avoid repeating work when older transactions are aborted and restarted.
  • priorities based upon a timestamp of when a transaction first started promotes fairness in that over time as a transaction ages it has a higher likelihood of winning in a conflict.
  • the priority 160 also can be contingent on how much data a transaction has accessed or how much computation the transaction has performed. As a transaction progresses the priority may be increased at various points, reflecting the increased progress. As in the timestamp approach, the priority can be used as a measure of how much work would be repeated if a transaction were to be aborted and restarted. As yet another alternative, the priority can depend upon whether the transaction has been blocked or aborted and restarted. Specifically on a block/abort or in the face of repeated blocks/aborts, the priority 160 can be increased in order to promote fairness and forward progress of the transaction.
  • each priority 160 can be evaluated in conflict arbitration performed by a conflict arbitration process 300 for the transactional memory 140 as defined within the implementation of the ISA and semantics 130 in the multiprocessor hardware HOA. In this way, the mechanism by which conflicts in the transactional memory 140 are arbitrated can remain separate from the algorithm by which the priorities 160 are established for each of the transactions 150. Further, though the priorities 160 can be established differently through changes in the external priority assignment logic 120 provided by software support HOB, the conflict arbitration process 300 can remain unaffected.
  • Figure 2 is a schematic illustration of a multiprocessor computing system configured for software prioritization of concurrent transactions for embedded conflict arbitration in transactional memory management.
  • the system can be a multiprocessor computing system 210A including multiple different processors 230 in a multiprocessor arrangement 220, each coupled to common memory 250.
  • the multiprocessor computing system 210A can support the operation of an operating system 210B executing on top of the multiprocessor computing system 210A.
  • Each of the processors 230 can provide an ISA and semantics supporting a transactional memory manager 240 managing read and write sets of transactions to memory 250.
  • conflict arbitration logic 300 can be coupled to the transactional memory manager 240.
  • the conflict arbitration logic 300 is enabled to arbitrate a set of transactions attempting to access a same block of the memory 250 according to the priorities 280 associated with the set of transactions.
  • different registers within each processor 230 can be allocated for storing priorities 280 corresponding to different transactions pending to be committed to memory 250.
  • Conflict priority establishment logic 290 can be disposed within the operating system 210B and can enjoy access to the priorities 280 as can other application code in order to establish individual ones of the priorities 280.
  • the conflict arbitration logic 300 can be enabled in response to detecting a conflict for a set of transactions to retrieve corresponding ones of the priorities 280 and to apply conflict arbitration based upon the retrieved corresponding ones of the priorities 280 in order to resolve the detected conflict. Options include aborting lower priority transactions, or forcing a wait on individual ones of the transactions lacking a requisite priority.
  • the conflict arbitration control value 270 can specify the type and nature of actions to be performed when arbitrating a conflict amongst a set of conflicted transactions pending to be committed to memory 250 according to the respective priorities 280.
  • the conflict arbitration control value 270 can specify the disabling of transaction blocking thereby forcing a complete abort for each transaction of lower priority than the highest priority transaction in conflict.
  • the conflict arbitration control value 270 can permit blocking of conflicted transactions in order to avoid the forcing of an abort for each transaction of lower priority than the highest priority transaction in conflict.
  • the conflict arbitration control value 270 can specify the permitting of hardware blocking of a conflicted transaction of lower priority, or the conflict arbitration control value 270 can specify the requirement that blocking is performed in software triggered by a hardware generated interrupt.
  • the conflict arbitration control value 270 can specify a duration of blocking for a transaction when blocking is permitted, in terms of time (e.g. milliseconds) or machine cycles. Also, the conflict arbitration control value 270 can enable adaptive hardware backoff so that when specified, the adaptive hardware backoff can require a lengthening of the duration as conflicts repeatedly occur with respect to a transaction. Even yet further, the conflict arbitration control value 270 can provide a limitation on how often a transaction can be blocked in conflict rather than aborted. Once a threshold limitation of repeated conflicts within a specified period of time has been detected for a transaction, when specified by the conflict arbitration control value 270, the transaction can be forced to abort upon a next occurring conflict.
  • the conflict arbitration control value 270 can specify the generation of an interrupt for software arbitration of a conflict amongst two or more transactions with equal corresponding ones of the priorities 280.
  • Figure 3 is a flow chart illustrating a process for software prioritization of concurrent transactions for embedded conflict arbitration in transactional memory management.
  • a conflict can be detected in connection with a block of memory and a set of transactions.
  • the priorities for each of the transactions in the set can be retrieved and in block 315, a conflict arbitration control parameter can be retrieved to determine the type and nature of actions that can be taken when arbitrating a conflict according to the priorities of the involved transactions.
  • a transaction can be selected amongst the set of transactions.
  • the retrieved conflict arbitration control policy can be applied to the transaction in respect to the priority for the selected transaction. Also, in decision block 330, if it is determined to abort the selected transaction, in block 335 the selected transaction can be aborted. Otherwise, in block 340, if it is determined to block the selected transaction, in block 345 the selected transaction can be blocked for some time period of time associated with a conflict arbitration control value. In either circumstance, in decision block 350, if additional transactions remain to be processed in the transaction set, the process can return to block 320 with the selection of a next transaction in the transaction set.
  • Embodiments of the invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements.
  • the invention is implemented in any of firmware, resident software, microcode, and the like.
  • the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system.
  • a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
  • the medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium.
  • Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk.
  • Current examples of optical disks include compact disk - read only memory (CD-ROM), compact disk - read/write (CD-R/W) and DVD.
  • a data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus.
  • the memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
  • I/O devices including but not limited to keyboards, displays, pointing devices, etc.
  • I/O controllers can be coupled to the system either directly or through intervening I/O controllers.
  • Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multi Processors (AREA)

Abstract

Embodiments of the present invention provide a method, system and computer program product for software prioritization of concurrent transactions for embedded conflict arbitration in transactional memory management. In an embodiment of the invention, a method for software prioritization of concurrent transactions for embedded conflict arbitration in transactional memory management can include setting different hardware registers with different priority values for correspondingly different transactions in a transactional memory system configured for transactional memory management according to respective priority values specified by priority assignment logic in external software support for the system. The method also can include detecting a conflict amongst the transactions in the system. Finally, the method can include applying conflict arbitration within the system based upon the priority values specified by the priority assignment logic in the external software support for the system.

Description

PRIORITIZATION FOR CONFLICT ARBITRATION IN TRANSACTIONAL MEMORY MANAGEMENT
BACKGROUND OF THE INVENTION
Field of the Invention
The present invention relates to the field of transactional memory utilization in parallel computing and more particularly to conflict arbitration in transactional memory management.
Description of the Related Art
Transactional memory techniques attempt to simplify parallel programming by allowing a group of load and store instructions to execute in an atomic way. Generally speaking, transactional memory is a concurrency control mechanism analogous to database transactions for controlling access to shared memory in concurrent computing. However, unlike the locking techniques used in most modern multithreaded applications, transactional memory can be viewed as optimistic in that a thread completes modifications to shared memory without regard for the activities of other threads, while recording every performed read and write and buffering the speculative changes to memory.
Transactions conflict when two or more transactions access the same block of memory, and at least one of those accesses is a write access. When utilizing transactional memory, instead of placing the onus on the reader or writer of a block of memory to ensure that the execution of a transaction does not conflict with other transactions in progress, the onus is placed on the transactional memory system to verify that other threads have not concurrently made conflicting references to the block of memory. Such a transactional memory system can be realized in software, hardware, or a combination of the two. The operation in which memory references are checked against other concurrent memory references is often referred to as validation. If validation is successful, at the conclusion of a transaction all memory changes are made permanent in an operation often referred to as a commit. Yet, a transaction can abort at any time, causing all of prior changes performed by the transaction to be rolled back or undone. If a transaction cannot be committed due to conflicting changes, the transaction can be aborted and re-executed from the beginning until the transaction succeeds.
It will be recognized by the skilled artisan, then, that the benefit of the optimistic approach of transactional memory is increased concurrency. Specifically, in the optimistic approach known in the art, no thread of execution needs to wait to access a block of memory. Further, different threads of execution can safely and simultaneously modify disjoint parts of a data structure that would otherwise be protected under the same lock. Overall, despite the overhead incurred in retrying failed transactions, in many realistic programs conflicts arise rarely enough that transactional memory techniques may provide an immense performance gain over lock-based protocols on large numbers of processors.
Conflict arbitration is the mechanism for deciding which transactions will be blocked or aborted when a conflict occurs, and which transactions will be allowed to continue execution. Conflict arbitration is controlled by an underlying contention management policy. Simple conflict arbitration mechanisms have been proposed for transactional memory systems, such as aborting a transaction when the transaction attempts to access data conflicting with an access of the same data by another active transaction. More recent research, however, has indicated the importance of better contention management. Better contention management avoids "livelock" that becomes possible in simple contention management policies, and better contention management can substantially improve performance in the case of frequent conflicts. A sophisticated contention management policy can combine the temporary blocking of a transaction attempting a conflicting access while awaiting a successful commit by a competing transaction, with heuristics to maximize transaction throughput, and also with mechanisms to improve fairness or provide better guarantees of forward progress. Even still, while some contention management policies demonstrate good performance across a set of benchmarks or applications, no single policy has been found that is universally optimal. BRIEF SUMMARY OF THE INVENTION
Embodiments of the present invention address deficiencies of the art in respect to conflict arbitration for transactional memory systems and provide a novel and non-obvious method, system and computer program product for software prioritization of concurrent transactions for embedded conflict arbitration in transactional memory management. In an embodiment of the invention, a method for software prioritization of concurrent transactions for embedded conflict arbitration in transactional memory management can include setting different hardware registers with different priority values for correspondingly different transactions in a system configured for transactional memory management according to respective priority values specified by priority assignment logic in external software support for the system.
The method also can include detecting a conflict amongst the transactions in the system. Finally, the method can include applying conflict arbitration within the system based upon the priority values specified by the priority assignment logic in the external software support for the system. Priorities values form the basis of the conflict arbitration mechanism and implement a contention management policy. Having software control the priority values allows for the use of different contention management policies as appropriate for each benchmark or application.
In one aspect of the embodiment, the method also can include retrieving a conflict arbitration control value from another register in the system. The conflict arbitration control value can specify at least one of a type and a nature of a conflict arbitration action. As such, the application of the conflict arbitration can be limited to at least one of a type and a nature of a conflict arbitration action specified by the conflict arbitration control value. In another aspect of the embodiment, the different priority values can be limited to a range of priority values able to be specified by the priority assignment logic in the external software support for the system.
In yet another aspect of the embodiment, applying conflict arbitration within the system based upon the priority values specified by the priority assignment logic in the external software support for the system can include blocking a selected one of the transactions having a lower priority than others of the transactions. Alternatively, applying conflict arbitration within the system based upon the priority values specified by the priority assignment logic in the external software support for the system can include aborting a selected one of the transactions having a lower priority than others of the transactions. As another alternative, applying conflict arbitration within the system based upon the priority values specified by the priority assignment logic in the external software support for the system can include detecting at least two of the transactions with equal priorities and generating an interrupt to the external software support to perform conflict arbitration for the at least two of the transactions in lieu of the system performing the conflict arbitration.
In another embodiment of the invention, a multiprocessor computer data processing system can be provided. The system can include multiple different processors coupled to memory in hardware and a transaction manager supported by an instruction set architecture (ISA) for each of the processors. The system also can include registers disposed in each of the processors. The registers can store priority values for transactions accessing memory managed by the transaction manager. Conflict arbitration logic also can be disposed in the system. The logic can include hardware or software enabled to apply conflict arbitration to conflicting ones of the transactions according to the priority values corresponding to the conflicting ones of the transactions. Finally, the system can include software support coupled to the hardware and configured to access the registers to set the priority values.
Additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The aspects of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed. BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
The accompanying drawings, which are incorporated in and constitute part of this specification, illustrate embodiments of the invention and together with the description, serve to explain the principles of the invention. The embodiments illustrated herein are presently preferred, it being understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown, wherein:
Figure 1 is a pictorial illustration of a process for software prioritization of concurrent transactions for embedded conflict arbitration in transactional memory management;
Figure 2 is a schematic illustration of a multiprocessor computing system configured for software prioritization of concurrent transactions for embedded conflict arbitration in transactional memory management; and,
Figure 3 is a flow chart illustrating a process for software prioritization of concurrent transactions for embedded conflict arbitration in transactional memory management.
DETAILED DESCRIPTION OF THE INVENTION
Embodiments of the present invention provide a method, system and computer program product for software prioritization of concurrent transactions for embedded conflict arbitration in transactional memory management. In accordance with an embodiment of the present invention, a multiprocessor computing system can be configured for transactional memory management. Each processor in the system can include externally accessible registers storing priority values for corresponding transactions executed by the processor. Conflict arbitration logic is provided in the transactional memory system and arbitrates conflicted transactions according to externally established priority values stored in the registers corresponding to the conflicted transactions as directed by program code external to the processor. In this way, the conflict arbitration logic of the system can arbitrate conflicts for conflicted transactions without regard to the algorithm establishing the priority values. In further illustration, Figure 1 is a pictorial illustration of a process for software prioritization of concurrent transactions for embedded conflict arbitration in transactional memory management. As shown in Figure 1, multiprocessor hardware HOA can combine with software support HOB such as a multiprocessor configured operating system to provide a multiprocessor computing system. The multiprocessor hardware 11OA can implement an
ISA and semantics 130 configured for transactional memory 140 across multiple different processors. In this regard, different processors can perform read and write transactions 150 on the transactional memory 140.
Notably, a priority 160 can be associated with each of the transactions 150. However, the priority 160 while stored in the multiprocessor hardware 11OA, for example in internal registers, can be accessed and set by external priority assignment logic 120 provided by software support HOB. Optionally, the external priority assignment logic 120 when granted only non-privileged access to the internal registers storing the priority 160 can be limited to assigning a priority within a range of priority values. However, when granted privileged access to the internal registers storing the priority 160, the external priority assignment logic 120 can assign priority values above or below the default range of values.
The priority 160 can be dependent upon how long a transaction has been running and can be a function of the time accounting for when the transaction first started, with an earlier start time being assigned a higher priority value. In this regard, in response to an abort and restart condition, the original start time of the transaction can be reused to set the priority so that the assigned priority is the same as when the transaction was first attempted. Such a timestamp- based approach can be desirable to avoid repeating work when older transactions are aborted and restarted. Further, priorities based upon a timestamp of when a transaction first started promotes fairness in that over time as a transaction ages it has a higher likelihood of winning in a conflict.
The priority 160 also can be contingent on how much data a transaction has accessed or how much computation the transaction has performed. As a transaction progresses the priority may be increased at various points, reflecting the increased progress. As in the timestamp approach, the priority can be used as a measure of how much work would be repeated if a transaction were to be aborted and restarted. As yet another alternative, the priority can depend upon whether the transaction has been blocked or aborted and restarted. Specifically on a block/abort or in the face of repeated blocks/aborts, the priority 160 can be increased in order to promote fairness and forward progress of the transaction.
In any event, once established, though, each priority 160 can be evaluated in conflict arbitration performed by a conflict arbitration process 300 for the transactional memory 140 as defined within the implementation of the ISA and semantics 130 in the multiprocessor hardware HOA. In this way, the mechanism by which conflicts in the transactional memory 140 are arbitrated can remain separate from the algorithm by which the priorities 160 are established for each of the transactions 150. Further, though the priorities 160 can be established differently through changes in the external priority assignment logic 120 provided by software support HOB, the conflict arbitration process 300 can remain unaffected.
The process described in Figure 1 can be implemented within an ISA and semantics for a multiprocessor computing system. In illustration, Figure 2 is a schematic illustration of a multiprocessor computing system configured for software prioritization of concurrent transactions for embedded conflict arbitration in transactional memory management. The system can be a multiprocessor computing system 210A including multiple different processors 230 in a multiprocessor arrangement 220, each coupled to common memory 250. Further, the multiprocessor computing system 210A can support the operation of an operating system 210B executing on top of the multiprocessor computing system 210A.
Each of the processors 230 can provide an ISA and semantics supporting a transactional memory manager 240 managing read and write sets of transactions to memory 250. In that conflicts can arise in respect to the concurrent writing or reading or transactions to a same block of the memory 250, conflict arbitration logic 300 can be coupled to the transactional memory manager 240. In particular, the conflict arbitration logic 300 is enabled to arbitrate a set of transactions attempting to access a same block of the memory 250 according to the priorities 280 associated with the set of transactions. Specifically, different registers within each processor 230 can be allocated for storing priorities 280 corresponding to different transactions pending to be committed to memory 250. Conflict priority establishment logic 290 can be disposed within the operating system 210B and can enjoy access to the priorities 280 as can other application code in order to establish individual ones of the priorities 280. The conflict arbitration logic 300, in turn, can be enabled in response to detecting a conflict for a set of transactions to retrieve corresponding ones of the priorities 280 and to apply conflict arbitration based upon the retrieved corresponding ones of the priorities 280 in order to resolve the detected conflict. Options include aborting lower priority transactions, or forcing a wait on individual ones of the transactions lacking a requisite priority.
An additional register or registers within each processor 230 can be allocated to store a conflict arbitration control value 270. The conflict arbitration control value 270 can specify the type and nature of actions to be performed when arbitrating a conflict amongst a set of conflicted transactions pending to be committed to memory 250 according to the respective priorities 280. For example, the conflict arbitration control value 270 can specify the disabling of transaction blocking thereby forcing a complete abort for each transaction of lower priority than the highest priority transaction in conflict. In contrast, the conflict arbitration control value 270 can permit blocking of conflicted transactions in order to avoid the forcing of an abort for each transaction of lower priority than the highest priority transaction in conflict. As yet another alternative, the conflict arbitration control value 270 can specify the permitting of hardware blocking of a conflicted transaction of lower priority, or the conflict arbitration control value 270 can specify the requirement that blocking is performed in software triggered by a hardware generated interrupt.
Notably, the conflict arbitration control value 270 can specify a duration of blocking for a transaction when blocking is permitted, in terms of time (e.g. milliseconds) or machine cycles. Also, the conflict arbitration control value 270 can enable adaptive hardware backoff so that when specified, the adaptive hardware backoff can require a lengthening of the duration as conflicts repeatedly occur with respect to a transaction. Even yet further, the conflict arbitration control value 270 can provide a limitation on how often a transaction can be blocked in conflict rather than aborted. Once a threshold limitation of repeated conflicts within a specified period of time has been detected for a transaction, when specified by the conflict arbitration control value 270, the transaction can be forced to abort upon a next occurring conflict. Alternatively, once the threshold limitation has been reached, an interrupt can be generated to trigger software arbitration of the conflict. Finally, the conflict arbitration control value 270 can specify the generation of an interrupt for software arbitration of a conflict amongst two or more transactions with equal corresponding ones of the priorities 280.
In further illustration of the conflict arbitration logic 300, Figure 3 is a flow chart illustrating a process for software prioritization of concurrent transactions for embedded conflict arbitration in transactional memory management. Beginning in block 305, a conflict can be detected in connection with a block of memory and a set of transactions. In block 310, the priorities for each of the transactions in the set can be retrieved and in block 315, a conflict arbitration control parameter can be retrieved to determine the type and nature of actions that can be taken when arbitrating a conflict according to the priorities of the involved transactions. Thereafter, in block 320 a transaction can be selected amongst the set of transactions.
In block 325, the retrieved conflict arbitration control policy can be applied to the transaction in respect to the priority for the selected transaction. Also, in decision block 330, if it is determined to abort the selected transaction, in block 335 the selected transaction can be aborted. Otherwise, in block 340, if it is determined to block the selected transaction, in block 345 the selected transaction can be blocked for some time period of time associated with a conflict arbitration control value. In either circumstance, in decision block 350, if additional transactions remain to be processed in the transaction set, the process can return to block 320 with the selection of a next transaction in the transaction set.
Embodiments of the invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in any of firmware, resident software, microcode, and the like. Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system.
For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk - read only memory (CD-ROM), compact disk - read/write (CD-R/W) and DVD.
A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus.
The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution. Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers. Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.

Claims

1. A method for software prioritization of concurrent transactions for embedded conflict arbitration in transactional memory management, the method comprising: setting different hardware registers with different priority values for correspondingly different transactions in a transactional memory system configured for transactional memory management according to respective priority values specified by priority assignment logic in external software support for the system; detecting a conflict amongst the transactions in the system; and, applying conflict arbitration within the system based upon the priority values specified by the priority assignment logic in the external software support for the system.
2. The method of claim 1, further comprising: retrieving a conflict arbitration control value from another register in the system, the conflict arbitration control value specifying at least one of type and a nature of a conflict arbitration action; and, limiting the applying of the conflict arbitration to at least one of a type and a nature of a conflict arbitration action specified by the conflict arbitration control value.
3. The method of claim 1 or 2, further comprising limiting the different priority values to a range of priority values able to be specified by the priority assignment logic in the external software support for the system.
4. The method of claim 1, 2 or 3, wherein applying conflict arbitration within the system based upon the priority values specified by the priority assignment logic in the external software support for the system, comprises blocking a selected one of the transactions having a lower priority than others of the transactions.
5. The method of claim 1, 2, 3 or 4, wherein applying conflict arbitration within the system based upon the priority values specified by the priority assignment logic in the external software support for the system, comprises aborting a selected one of the transactions having a lower priority than others of the transactions.
6. The method of any one of claims 1 to 5, wherein applying conflict arbitration within the system based upon the priority values specified by the priority assignment logic in the external software support for the system, comprises: detecting at least two of the transactions with equal priorities; and, generating an interrupt to the external software support to perform conflict arbitration for the at least two of the transactions in lieu of the processor performing the conflict arbitration.
7. The method of claim 4, wherein blocking a selected one of the transactions having a lower priority than others of the transactions, comprises blocking a selected one of the transactions having a lower priority than others of the transactions for a duration of time that increases each time the selected one of the transactions is detected to conflict with the others of the transactions.
8. The method of claim 4, wherein blocking a selected one of the transactions having a lower priority than others of the transactions, comprises: blocking a selected one of the transactions having a lower priority than others of the transactions for a duration of time that increases each time the selected one of the transactions is detected to conflict with the others of the transactions, until a threshold number of conflicts are detected; and, upon exceeding the threshold number of conflicts for the selected one of the transactions, forcing an abort of the selected one of the transactions.
9. A multiprocessor computer data processing system comprising: a plurality of processors coupled to memory in hardware; a transaction manager implemented in an instruction set architecture (ISA) and semantics for each of the processors; registers disposed in each of the processors, the registers storing priority values for transactions accessing memory managed by the transaction manager; conflict arbitration logic disposed in the system, the logic enabled to apply conflict arbitration to conflicting ones of the transactions according to the priority values corresponding to the conflicting ones of the transactions; and, software support coupled to the hardware and configured to access the registers to set the priority values.
10. The system of claim 9, further comprising a register in each of the processors specifying a conflict arbitration control value, the conflict arbitration control value specifying one of a type and nature of conflict arbitration actions able to be performed for conflicting ones of the transactions.
11. A computer program product comprising a computer usable medium embodying computer usable program code for software prioritization of concurrent transactions for embedded conflict arbitration in transactional memory management, the computer program product comprising: computer usable program code for setting different hardware registers with different priority values for correspondingly different transactions in a system configured for transactional memory management according to respective priority values specified by priority assignment logic in external software support for the system; computer usable program code for detecting a conflict amongst the transactions in the system; and, computer usable program code for applying conflict arbitration within the processor based upon the priority values specified by the priority assignment logic in the external software support for the system.
12. The computer program product of claim 11, further comprising: computer usable program code for retrieving a conflict arbitration control value from another register in the processor, the conflict arbitration control value specifying at least one of type and a nature of a conflict arbitration action; and, computer usable program code for limiting the applying of the conflict arbitration to at least one of a type and a nature of a conflict arbitration action specified by the conflict arbitration control value.
13. The computer program product of claim 11 or 12, further comprising computer usable program code for limiting the different priority values to a range of priority values able to be specified by the priority assignment logic in the external software support for the system.
14. The computer program product of claim 11, 12 or 13, wherein the computer usable program code for applying conflict arbitration within the processor based upon the priority values specified by the priority assignment logic in the external software support for the system, comprises computer usable program code for blocking a selected one of the transactions having a lower priority than others of the transactions.
15. The computer program product of any one of claims 11 to 14, wherein the computer usable program code for applying conflict arbitration within the system based upon the priority values specified by the priority assignment logic in the external software support for the system, comprises computer usable program code for aborting a selected one of the transactions having a lower priority than others of the transactions.
EP09799620A 2009-01-02 2009-12-18 Prioritization for conflict arbitration in transactional memory management Withdrawn EP2362955A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12/348,216 US9170844B2 (en) 2009-01-02 2009-01-02 Prioritization for conflict arbitration in transactional memory management
PCT/EP2009/067496 WO2010076239A1 (en) 2009-01-02 2009-12-18 Prioritization for conflict arbitration in transactional memory management

Publications (1)

Publication Number Publication Date
EP2362955A1 true EP2362955A1 (en) 2011-09-07

Family

ID=41666434

Family Applications (1)

Application Number Title Priority Date Filing Date
EP09799620A Withdrawn EP2362955A1 (en) 2009-01-02 2009-12-18 Prioritization for conflict arbitration in transactional memory management

Country Status (5)

Country Link
US (1) US9170844B2 (en)
EP (1) EP2362955A1 (en)
JP (1) JP5467661B2 (en)
CN (1) CN102272744B (en)
WO (1) WO2010076239A1 (en)

Families Citing this family (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8973004B2 (en) * 2009-06-26 2015-03-03 Oracle America, Inc. Transactional locking with read-write locks in transactional memory systems
US8332855B2 (en) * 2009-07-09 2012-12-11 Qualcomm Incorporated Method and apparatus for assigning priorities to composite events
US8719828B2 (en) * 2011-10-14 2014-05-06 Intel Corporation Method, apparatus, and system for adaptive thread scheduling in transactional memory systems
US9361115B2 (en) * 2012-06-15 2016-06-07 International Business Machines Corporation Saving/restoring selected registers in transactional processing
US9384004B2 (en) 2012-06-15 2016-07-05 International Business Machines Corporation Randomized testing within transactional execution
US20130339680A1 (en) 2012-06-15 2013-12-19 International Business Machines Corporation Nontransactional store instruction
US8688661B2 (en) 2012-06-15 2014-04-01 International Business Machines Corporation Transactional processing
US8682877B2 (en) 2012-06-15 2014-03-25 International Business Machines Corporation Constrained transaction execution
US10437602B2 (en) 2012-06-15 2019-10-08 International Business Machines Corporation Program interruption filtering in transactional execution
US9772854B2 (en) 2012-06-15 2017-09-26 International Business Machines Corporation Selectively controlling instruction execution in transactional processing
US9336046B2 (en) 2012-06-15 2016-05-10 International Business Machines Corporation Transaction abort processing
US9448796B2 (en) 2012-06-15 2016-09-20 International Business Machines Corporation Restricted instructions in transactional execution
US9436477B2 (en) 2012-06-15 2016-09-06 International Business Machines Corporation Transaction abort instruction
US9348642B2 (en) 2012-06-15 2016-05-24 International Business Machines Corporation Transaction begin/end instructions
US9367323B2 (en) 2012-06-15 2016-06-14 International Business Machines Corporation Processor assist facility
US9442737B2 (en) * 2012-06-15 2016-09-13 International Business Machines Corporation Restricting processing within a processor to facilitate transaction completion
US9740549B2 (en) 2012-06-15 2017-08-22 International Business Machines Corporation Facilitating transaction completion subsequent to repeated aborts of the transaction
US20150074219A1 (en) * 2013-07-12 2015-03-12 Brocade Communications Systems, Inc. High availability networking using transactional memory
CN104572506B (en) * 2013-10-18 2019-03-26 阿里巴巴集团控股有限公司 A kind of method and device concurrently accessing memory
US9323568B2 (en) 2014-01-24 2016-04-26 International Business Machines Corporation Indicating a low priority transaction
US9317379B2 (en) 2014-01-24 2016-04-19 International Business Machines Corporation Using transactional execution for reliability and recovery of transient failures
US9304935B2 (en) 2014-01-24 2016-04-05 International Business Machines Corporation Enhancing reliability of transaction execution by using transaction digests
US9424071B2 (en) 2014-01-24 2016-08-23 International Business Machines Corporation Transaction digest generation during nested transactional execution
US9465746B2 (en) 2014-01-24 2016-10-11 International Business Machines Corporation Diagnostics for transactional execution errors in reliable transactions
US9454313B2 (en) * 2014-06-10 2016-09-27 Arm Limited Dynamic selection of memory management algorithm
US9524257B2 (en) 2014-06-27 2016-12-20 International Business Machines Corporation Transactional execution enabled supervisor call interruption while in TX mode
GB2546232A (en) * 2015-06-16 2017-07-19 Nordic Semiconductor Asa Integrated circuit inputs and outputs
US9792147B2 (en) * 2015-07-02 2017-10-17 International Business Machines Corporation Transactional storage accesses supporting differing priority levels
US10346196B2 (en) * 2015-08-11 2019-07-09 Oracle International Corporation Techniques for enhancing progress for hardware transactional memory
US10133767B1 (en) 2015-09-28 2018-11-20 Amazon Technologies, Inc. Materialization strategies in journal-based databases
US10198346B1 (en) * 2015-09-28 2019-02-05 Amazon Technologies, Inc. Test framework for applications using journal-based databases
US10331657B1 (en) 2015-09-28 2019-06-25 Amazon Technologies, Inc. Contention analysis for journal-based databases
CN106648440B (en) 2015-10-28 2020-07-24 华为技术有限公司 Control method and storage device for operating storage device
US20180329900A1 (en) * 2015-11-19 2018-11-15 Entit Software Llc Prediction models for concurrency control types
US9792148B2 (en) 2016-01-07 2017-10-17 International Business Machines Corporation Prioritization of transactions based on execution progress
CN107533474B (en) * 2016-01-26 2020-07-07 华为技术有限公司 A transaction processing method and device
US9772874B2 (en) 2016-01-29 2017-09-26 International Business Machines Corporation Prioritization of transactions based on execution by transactional core with super core indicator
CN107329913B (en) * 2016-04-28 2019-12-13 深圳市中兴微电子技术有限公司 Access control method and device
US10572399B2 (en) * 2016-07-13 2020-02-25 Qualcomm Incorporated Memory request arbitration
US10114776B2 (en) * 2016-11-03 2018-10-30 Microchip Technology Incorporated System arbiter with programmable priority levels
US10496577B2 (en) * 2017-02-09 2019-12-03 Hewlett Packard Enterprise Development Lp Distribution of master device tasks among bus queues
US10558604B2 (en) * 2017-12-20 2020-02-11 Qualcomm Incorporated Communication interface transaction security
CN109640341A (en) * 2018-12-25 2019-04-16 全球能源互联网研究院有限公司 The processing method and electronic equipment of signal interference
CN111159022B (en) * 2019-12-20 2023-05-02 北京轩宇信息技术有限公司 Interrupt data access conflict detection method and device based on univariate access sequence mode
US11341071B1 (en) * 2021-04-20 2022-05-24 Dell Products L.P. Arbitrating serial bus access
CN113420468B (en) * 2021-08-24 2021-11-19 中电烽友信息技术(武汉)有限公司 Data writing conflict processing method and system based on universal blackboard
US12026540B2 (en) 2022-01-13 2024-07-02 Kyndryl, Inc. Working memory management
CN117155871B (en) * 2023-10-31 2024-01-12 山东衡昊信息技术有限公司 Port industrial Internet point position low-delay concurrent processing method

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1852783A1 (en) * 2005-01-31 2007-11-07 Matsushita Electric Industrial Co., Ltd. Access arbiter and arbiterable condition verification device

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS61150059A (en) * 1984-12-24 1986-07-08 Sony Corp Data processor
US6195724B1 (en) * 1998-11-16 2001-02-27 Infineon Technologies Ag Methods and apparatus for prioritization of access to external devices
US7190023B2 (en) * 1999-09-17 2007-03-13 Renesas Technology Corp. Semiconductor integrated circuit having discrete trap type memory cells
US6516393B1 (en) * 2000-09-29 2003-02-04 International Business Machines Corporation Dynamic serialization of memory access in a multi-processor system
US6751711B1 (en) * 2000-10-27 2004-06-15 Nortel Networks Limited Methods and systems for process rollback in a shared memory parallel processor computing environment
JP2003114825A (en) 2001-10-04 2003-04-18 Hitachi Ltd Memory control method, memory control circuit using the control method, and integrated circuit incorporating the memory control circuit
JP4127354B2 (en) 2001-12-18 2008-07-30 富士通株式会社 Multiprocessor control program and multiprocessor control method
US7529800B2 (en) * 2003-12-18 2009-05-05 International Business Machines Corporation Queuing of conflicted remotely received transactions
JP2007094649A (en) 2005-09-28 2007-04-12 Kyocera Mita Corp Access arbitration circuit
US7720891B2 (en) * 2006-02-14 2010-05-18 Oracle America, Inc. Synchronized objects for software transactional memory
US7584332B2 (en) * 2006-02-17 2009-09-01 University Of Notre Dame Du Lac Computer systems with lightweight multi-threaded architectures
US7711678B2 (en) * 2006-11-17 2010-05-04 Microsoft Corporation Software transaction commit order and conflict management

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1852783A1 (en) * 2005-01-31 2007-11-07 Matsushita Electric Industrial Co., Ltd. Access arbiter and arbiterable condition verification device

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
MAURICE HERLIHY ET AL: "software transactional memory for dynamic-sized data structures", 13 July 2003 (2003-07-13), pages 92 - 101, XP002669600, ISBN: 978-1-58113-708-8, Retrieved from the Internet <URL:http://dl.acm.org/citation.cfm?id=872048&bnc=1> *
PETER DAMRON ET AL: "Hybrid transactional memory", INTERNATIONAL CONFERENCE ON ARCHITECTURAL SUPPORT FOR PROGRAMMING LANGUAGES AND OPERATING SYSTEMS ; 12TH (SAN JOSE, CALIF.) : 2006, 20 October 2006 (2006-10-20), pages 336 - 346, XP055226969, ISBN: 978-1-59593-451-2, DOI: 10.1145/1168857.1168900 *
See also references of WO2010076239A1 *
WILLIAM N SCHERER ET AL: "Advanced contention management for dynamic software transactional memory", PROCEEDINGS OF THE 24TH. ANNUAL ACM SYMPOSIUM ON PRINCIPLES OF DISTRIBUTED COMPUTING. PODC 2005, JULY 17-20, 2005, LAS VEGAS, NEVADA, USA, ACM, US, vol. 24, 17 July 2005 (2005-07-17), pages 240 - 248, XP002660214, ISBN: 978-1-58113-994-5, [retrieved on 20050717] *

Also Published As

Publication number Publication date
JP5467661B2 (en) 2014-04-09
US9170844B2 (en) 2015-10-27
US20100174840A1 (en) 2010-07-08
WO2010076239A1 (en) 2010-07-08
JP2012514780A (en) 2012-06-28
CN102272744B (en) 2014-12-03
CN102272744A (en) 2011-12-07

Similar Documents

Publication Publication Date Title
US9170844B2 (en) Prioritization for conflict arbitration in transactional memory management
US8789057B2 (en) System and method for reducing serialization in transactional memory using gang release of blocked threads
Attiya et al. Transactional scheduling for read-dominated workloads
US9513959B2 (en) Contention management for a hardware transactional memory
US6226717B1 (en) System and method for exclusive access to shared storage
US9996402B2 (en) System and method for implementing scalable adaptive reader-writer locks
Maldonado et al. Scheduling support for transactional memory contention management
US20080209422A1 (en) Deadlock avoidance mechanism in multi-threaded applications
US20070198978A1 (en) Methods and apparatus to implement parallel transactions
US20090006403A1 (en) Efficiently boosting priority of read-copy update readers while resolving races with exiting and unlocking processes
US20090138890A1 (en) Contention management for a hardware transactional memory
US10579413B2 (en) Efficient task scheduling using a locking mechanism
EP3114564B1 (en) Transactional memory support
US20150301871A1 (en) Busy lock and a passive lock for embedded load management
US11366689B2 (en) Hardware for supporting OS driven observation and anticipation based on more granular, variable sized observation units
US10360079B2 (en) Architecture and services supporting reconfigurable synchronization in a multiprocessing system
US20060161919A1 (en) Implementation of load linked and store conditional operations
US20120054394A1 (en) Fast Biased Locks
US20120166747A1 (en) Dynamic nest level determination for nested transactional memory rollback
US20050283783A1 (en) Method for optimizing pipeline use in a multiprocessing system
US8219762B1 (en) Computer system and method for leasing memory location to allow predictable access to memory location
US6701429B1 (en) System and method of start-up in efficient way for multi-processor systems based on returned identification information read from pre-determined memory location
EP3702911B1 (en) Hardware for supporting os driven load anticipation based on variable sized load units
US7996848B1 (en) Systems and methods for suspending and resuming threads
Mohamedin et al. On scheduling best-effort HTM transactions

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20110602

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20120911

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20160330