JP6642806B2 - Adaptive process for data sharing using lock invalidation and lock selection - Google Patents

Description

  The present disclosure relates generally to transaction memory systems, and more particularly, to methods, computer programs, and computers for adaptive sharing of data using lock elision and locking selection. -Regarding the system.

  To support the increasing demand for workload capacity, the number of central processing unit (CPU) cores on a chip and the number of CPU cores connected to shared memory continue to increase significantly. The increase in the number of CPUs working together to handle the same workload places a significant burden on software scalability, for example, shared queues or data structures protected by traditional semaphores become hotspots, This results in substantially linear n-way scaling curves. Traditionally, this is offset by the implementation of fine-grained locking in software and low-latency / high-bandwidth interconnects in hardware. Implementing fine-grained locks to improve software scalability can be very complex and error-prone, and at today's CPU frequencies, the latency of hardware interconnects is limited by chip and system requirements. And the speed of light.

  An implementation of a hardware transaction memory (HTM, or simply TM in this discussion) was introduced, where a group of instructions called a transaction was seen by other central processing units (CPUs) and I / O subsystems. At times, it operates in an atomic manner on data structures in memory (in other literature, atomic operations are also known as "block concurrent" or "serialized"). A transaction is executed optimistically without acquiring a lock, but if the operation of a running transaction on a memory location conflicts with another on the same memory location, the transaction execution aborts and restarts. May require trial. So far, software transaction memory implementations have been proposed to support software transaction memory (TM). However, hardware TM can provide improved performance aspects and ease of use over software TM.

  U.S. Pat. No. 6,083,838, filed Aug. 28, 2002 and incorporated herein by reference, teaches a method and apparatus for distributed cache synchronization, entitled "Method and Apparatus for the Synchronization of Distributed Caches." . More particularly, the present embodiments relate to cache memory systems and, more particularly, are suitable for use with distributed caches, including use within cache input / output (I / O) hubs. Related to the hierarchical cache protocol.

  Patent Document 2, entitled "Partial cache line write transactions in a computing system with a write back cache," filed March 24, 1994 and incorporated herein by reference, discloses a memory, processor, output / adapter. Teach the proposed computing system, including: The processor includes a write-back cache that can store dirty data. In performing a consistent write from an input / output adapter to memory, a block of data is written from the input / output adapter to a memory location in memory. A data block contains less data than a full cache line in the write-back cache. The write-back cache is searched to determine if the write-back cache contains data for that memory location. If the search determines that the write-back cache contains data for that memory location, the full cache line containing data for that memory location is purged.

US Patent Application Publication No. 2004/0044850 U.S. Pat. No. 5,586,297 US Patent No. 6,349,361

"Intel Architecture Construction Set Extensions Programming Reference," 319433-012A, February 2012. Austen McDonald, "ARCHITECTURES FOR TRANSACTIONAL MEMORY", a dissertation submitted to the Committee of the Computer Science Faculty and Graduate School at Stanford University, June 2009, as a partial fulfillment of the PhD requirements. "Transactional Architecture Architecture and Implementation for IBM Systems z", MICRO-45 Proceedings, December 1-5, 2012, Vancouver, British Columbia, Canada, pages 25-36, IEEE Computer ScienceCopiers. More available "Z / Architecture, Principles of Operation", 10th edition, IBM (registered trademark) SA22-7832-09, September 2012 P. Mark, C.I. Walters and G.W. Strait, "IBM system z10 processor cache subsystem microarchitecture", IBM Journal of Research and Development, Vol 53: 1, 2009.

  Methods, computer programs, and computer systems for adaptive sharing of data using lock invalidation and lock selection are provided.

  In a Hardware Lock Elimination (HLE) environment, a method is provided for an HLE transaction to actually acquire a lock and predictively determine whether to execute non-transactionally. According to one embodiment of the present disclosure, the method invalidates a lock and proceeds as an HLE transaction or acquires a lock based on an HLE predictor based on encountering an HLE lock-acquire instruction. And setting the address of the lock as a read set of the HLE transaction, based on the HLE predictor predicting that the invalidation will be performed, and setting the lock to the lock by the lock-acquire instruction. Preventing any writes and proceeding in HLE transaction execution mode until an xrelease instruction is encountered to release a lock or an HLE transaction encounters a transaction conflict, and the HLE predictor predicts that it will not invalidate Based on It may include a possible handling, By proceeding in a non-transactional mode HLE lock-The acquire instruction as a non HLE lock-The acquire instruction.

  In another embodiment of the present disclosure, there is provided a computer program product for a hardware lock elimination (HLE) environment in which an HLE transaction actually acquires a lock and predictively determines whether to execute non-transactionally. be able to. The computer program product is readable by a processing circuit and, upon encountering an HLE lock-acquire instruction, invalidates the lock based on the HLE predictor and proceeds as an HLE transaction or acquires the lock. And setting the address of the lock as a read set of the HLE transaction, based on the HLE predictor predicting that the invalidation will be performed, and setting the lock to the lock by the lock-acquire instruction. Proceed in HLE transaction execution mode until the xrelease instruction that suppresses any writes and releases the lock or the HLE transaction encounters a transaction conflict, and the HLE predictor invalidates. Storing the instructions executed by the processing circuitry to implement a method that, based on the expectation, treats the HLE lock-acquire instruction as a non-HLE lock-acquire instruction and proceeds in a non-transactional mode. Computer-readable storage media.

  In another embodiment of the present disclosure, a computer system is provided for determining in a Hardware Lock Elision (HLE) environment whether an HLE transaction actually acquires a lock and non-transactionally should execute. . The computer system may include a memory and a processor in communication with the memory, and based on encountering an HLE lock-acquire instruction, based on an HLE predictor, invalidates a lock and performs a HLE transaction. Setting the address of the lock as a read set of the HLE transaction based on deciding whether to proceed or acquire the lock and proceed as a non-transaction, and based on the prediction that the HLE predictor will invalidate inhibiting any write to the lock by the lock-acquire instruction and proceeding in HLE transaction execution mode until an xrelease instruction to release the lock or until the HLE transaction encounters a transaction conflict; Treating the HLE lock-acquire instruction as a non-HLE lock-acquire instruction and proceeding in a non-transaction mode based on the E-predictor predicting no invalidation. You.

  The features and advantages of the disclosed embodiments will become apparent from the following detailed description of exemplary embodiments, which should be read in conjunction with the accompanying drawings. The various features of the drawings are not to scale, as the illustrations are for the purpose of clarity when facilitating the understanding of the present disclosure in conjunction with the detailed description.

1 illustrates an exemplary multi-core transaction memory environment according to embodiments of the present disclosure. 1 illustrates an exemplary multi-core transaction memory environment according to embodiments of the present disclosure. 4 illustrates exemplary components of an exemplary CPU according to embodiments of the present disclosure. FIG. 3 illustrates a flow diagram of a method for adaptive sharing of data with lock invalidation and selection between locks, according to an exemplary hardware or software embodiment. FIG. 4 illustrates a flow diagram in which a contention predictor, also called an HLE predictor or hardware locked virtualizer, is implemented in an environment where HLE support is present. FIG. 7 illustrates a flow diagram of a method for adaptive sharing of data with lock invalidation and selection between locks, according to an exemplary embodiment in which no additional hardware capabilities are present. FIG. 4 illustrates a flow diagram of a method for adaptive sharing of data with lock invalidation and selection between locks, according to an exemplary embodiment with hardware lock monitoring. 4 shows an exemplary flow for adaptively sharing data. 4 shows an exemplary flow for adaptively sharing data. FIG. 8 is a schematic block diagram of hardware and software of a computer environment in accordance with at least one example embodiment of the methods of FIGS.

  In the past, computer systems or processors only had a single processor (aka processing unit or central processing unit). The processor included an instruction processing unit (IPU), a branch unit, a memory control unit, and the like. These processors could execute a single program thread at a time. Time-share the processor by dispatching a program to run on the processor for a period of time and then dispatching another program to run on the processor for another period of time A capable operating system was developed. As technology has evolved, complex dynamic address translations, including memory subsystem caches as well as translation lookaside buffers (TLBs), have often been added to processors. The IPU itself was often called a processor. As technology continues to evolve, the entire processor can be packaged as a single semiconductor chip or die, and such processors have been termed microprocessors. Subsequently, processors incorporating multiple IPUs were developed, and such processors were often referred to as multiprocessors. Each such processor of a multiprocessor computer system (processor) may include individual or shared caches, memory interfaces, system buses, address translation mechanisms, and the like. The virtual machine and instruction set architecture (ISA) emulator adds multiple layers of software to the processor and uses a single IPU time slice within a single hardware processor to create multiple "virtual processor" (Aka processor). As the technology evolves further, multi-threaded processors have been developed that enable a single hardware processor with a single multi-threaded IPU to provide the ability to execute threads of different programs simultaneously, and thus, a computer system. Now allows each thread of a multi-threaded processor to appear as one processor. As technology evolved further, it became possible to mount multiple processors (each with an IPU) on a single semiconductor chip or die. These processors were called processor cores, or simply cores. Thus, for example, terms such as processor, central processing unit, processing unit, microprocessor, core, processor core, processor thread and thread are often used interchangeably. Aspects of the embodiments herein may be implemented by any or all processors, including those set forth above, without departing from the teachings herein. As the terms "thread" or "processor thread" are used herein, it is believed that certain advantages of the embodiments could have been provided in the implementation of the processor thread.

Transaction Execution in Intel (R) -Based Embodiments In Non-Patent Document 1, Chapter 8, Partially, Multi-Threaded Applications Achieve Higher Performance It teaches that the increase in the number of CPU cores can be used for this purpose. However, writing a multithreaded application requires the programmer to understand and take into account data sharing between multiple threads. Access to shared data generally requires a synchronization mechanism. Multiple threads update shared data using these synchronization mechanisms, often using lock-protected critical sections to serialize the operations applied to the shared data. I guarantee you. Since serialization limits concurrency, programmers attempt to limit the overhead due to synchronization.

  Intel® Transactional Synchronization Extensions (Intel® TSX) dynamically determines whether a processor needs to serialize a thread with a lock-protected critical section and, if necessary, Only allows this serialization to be performed. This allows the processor to manifest and utilize the concurrency hidden in the application due to dynamic and unnecessary synchronization.

  In Intel (registered trademark) TSX, a code area (also referred to as a “transaction area” or simply “transaction”) designated by a programmer executes a transaction. Upon successful completion of a transaction execution, all memory operations performed within the transaction area appear to have occurred instantly to other processors. A processor may execute a memory operation of an executed transaction that is performed in a transaction area visible to other processors only if the commit is successful, i.e., only if the transaction has successfully completed execution. Do. This process is often called an atomic commit.

  Intel (R) TSX provides two software interfaces for specifying code regions for transaction execution. Hardware Lock Elimination (HLE) is a legacy compatible instruction set extension (including the XACQUIRE and XRELEASE prefixes) for specifying the transaction area. Restricted Transactional Memory (Restricted Transactional Memory, RTM) is a new instruction set interface (including XBEGIN, XEND, and XABORT instructions) that allows programmers to define transaction areas in a more flexible way than is possible with HLE. it can. HLE prefers the backward compatibility of the traditional mutual exclusion programming model and wants to run HLE-enabled software on legacy hardware, but provides a new lock override function on hardware with HLE support. For programmers who want to use it. RTM is for programmers who prefer a more flexible interface than transaction execution hardware. In addition, Intel (R) TSX also provides an XTEST instruction. This instruction allows software to query whether the logical processor is executing a transaction in the transaction area identified by either HLE or RTM.

  Because a successful transaction execution guarantees an atomic commit, the processor optimistically executes the code area without explicit synchronization. If synchronization is not required for a particular run, the run can be committed without any cross-thread serialization. If the processor cannot commit atomically, optimistic execution will fail. If the optimistic execution fails, the processor rolls back execution and the process is called a transaction abort. When a transaction aborts, the processor discards any updates made in the memory area used by the transaction, restores the architectural state as if it had not been optimistically executed, Resume execution.

  A processor may abort a transaction for a number of reasons. The main reason for aborting a transaction is due to contention for memory access between the logical processor executing the transaction and another logical processor. Such memory access contention may hinder successful transaction execution. The memory area read from the transaction area constitutes a read set of the transaction area, and the address written in the transaction area constitutes a write set of the transaction area. Intel (R) TSX maintains read and write sets at the granularity of cache lines. A memory access conflict occurs when another logical processor reads at some location in the transaction area write set or writes at some location in the transaction area read set or write set. Access contention generally means that the code area needs to be serialized. Since Intel (R) TSX detects data conflicts at the granularity of cache lines, extraneous data locations located on the same cache line are detected as conflicts, resulting in a transaction abort. Transaction aborts may also occur due to transaction resource limitations. For example, when the amount of data accessed in the area exceeds the capability inherent in the implementation. In addition, some instructions and system events may cause a transaction abort. Frequent transaction aborts result in wasted cycles and increased inefficiencies.

Hardware Lock Elion
Hardware Lock Elimination (HLE) is a conventional compatible instruction set interface for programmers to use transaction execution. HLE provides two new instruction prefix hints, XACQUIRE and XRELEASE.

  In HLE, the programmer adds the XACQUIRE prefix before the instruction used to acquire the lock that protects the critical section. The processor treats the prefix as a hint to elide the write associated with the lock acquisition operation. Even though the lock acquisition has a write operation associated with the lock, the processor does not add the address of the lock to the write set of the transaction area and does not issue any write requests for the lock. Instead, the address of the lock is added to the read set. The logical processor enters transaction execution. If a lock was available before the XACQUIRE-prefixed instruction, all other processors continue to consider the lock available after the instruction. The logical processor performing the transaction does not add the address of the lock to the write set and does not perform explicit write operations externally, so that other logical processors can read the lock without causing data contention. This allows other logical processors to enter the lock-protected critical section and execute concurrently. The processor automatically detects any data races caused during the execution of the transaction and performs a transaction abort as needed.

  The hardware guarantees the program order of operations on locks, even though the invalidating processor does not perform any external write operations on locks. When the invalidating processor itself reads the value of the lock in the critical section, it appears that the processor has acquired the lock, ie, the read returns a non-elide value. This behavior allows HLE execution to be functionally equivalent to execution without the HLE prefix.

  The XRELEASE prefix can be added before the instruction used to release the lock protecting the critical section. Releasing a lock includes writing to the lock. If this instruction returns the value of the lock to the value the lock had before the lock acquisition operation with the same lock's XACQUIRE prefix, the processor ignores any external write requests associated with releasing the lock. And does not add the address of the lock to the write set. Next, the processor attempts to commit the transaction execution.

  HLE allows multiple threads to execute critical sections protected by the same lock at the same time without serializing the threads, provided that they do not perform any conflicting operations on each other's data. Can be performed. If software uses a lock acquisition operation on a common lock, the hardware recognizes this, invalidates the lock, and executes the critical section in two threads without any communication through the lock (such as Communication was not needed dynamically).

  If the processor cannot transactionally execute the region, the processor executes the region non-transactionally and without invalidating. HLE-enabled software guarantees forward progress as well as the underlying non-HLE lock-based implementation. Lock and critical section code must follow certain guidelines for successful HLE execution. These guidelines only affect performance, and non-compliance with these guidelines does not result in functional failure. Hardware without HLE support ignores the XACQUIRE and XRELEASE prefix hints, but these prefixes correspond to the REPNE / REPE IA-32 prefixes that are ignored in the instruction when XACQUIRE and XRELEASE are enabled. Do not do any invalidation. Importantly, HLE is compatible with existing lock-based programming models. Although improper use of hints does not cause a functional bug. Potential bugs already in the code may be exposed.

  Restricted Transactional Memory (RTM) provides a flexible software interface for executing transactions. RTM provides three new instructions (XBEGIN, XEND, and XABORT) that allow the programmer to start, commit, and abort transaction execution.

  The programmer specifies the start of the transaction code area using the XBEGIN instruction, and specifies the end of the transaction code area using the XEND instruction. The XBEGIN instruction utilizes an operand that provides a relative offset to the fallback instruction address if the RTM area did not successfully execute the transaction.

  A processor may abort RTM transaction execution for a number of reasons. The hardware automatically detects a transaction abort condition and resumes execution from the fallback instruction address with the start of the XBEGIN instruction and the architected state corresponding to the EAX register updated to account for abort status. I do.

  The XABORT instruction allows the programmer to explicitly abort execution of the RTM region. The XABORT instruction utilizes an 8-bit immediate argument loaded into the EAX register that becomes available in software after an RTM abort. The RTM instruction is not associated with any data memory location. Although the hardware does not guarantee that the RTM region has ever successfully committed a transaction, most transactions that follow the recommended guidelines are expected to succeed. However, the programmer must always provide an alternative code sequence in the fallback path to guarantee forward progress. This can be as simple as acquiring a lock and executing the specified code region non-transactionally. Furthermore, a transaction that is always aborted in a given implementation may complete in a future implementation. Therefore, the programmer must ensure that the code areas of the transaction area and the alternative code sequence are functionally tested.

HLE support detection Processor is CPUID. 07H. EBX. When HLE [bit4] = 1, HLE execution is supported. However, applications can use HLE prefixes (XACQUIRE and XRELEASE) without checking whether the processor supports HLE. Processors without HLE support ignore these prefixes and execute code without entering transaction execution.

Detection of RTM support Processor is CPUID. 07H. EBX. When RTM [bit11] = 1, RTM execution is supported. Before using an RTM instruction (XBEGIN, XEND, XABORT), the application needs to check if the processor supports RTM. When these instructions are used in a processor that does not support RTM, a #UD exception occurs.

XTEST instruction detection If the processor supports either HLE or RTM, it will support the XTEST instruction. The application needs to check either of these feature flags before using the XTEST instruction. If this instruction is used in a processor that does not support either HLE or RTM, a #UD exception will occur.

Querying Transaction Execution Status The XTEST instruction can be used to determine the transaction status of a transaction area specified by HLE or RTM. Note that the HLE prefix is ignored on processors that do not support HLE, but the XTEST instruction raises a #UD exception when used on a processor that does not support either HLE or RTM. I want to.

HLE Lock Requirements For an HLE execution to succeed in a transaction commit, the lock must meet certain characteristics and access to the lock must follow the following specific guidelines:

  The XRELEASE prefixed instruction needs to restore the value of the invalidated lock to the value it had before the lock was acquired. This allows the hardware to safely disable the lock without adding it to the write set. The data size and data address of the release lock (with the XRELEASE prefix) instruction must match that of the acquire lock (with the XACQUIRE prefix) instruction, and the lock must cross cache line boundaries. Can not.

  Software should not write to an invalidated lock in the transaction HLE area with any instruction other than the XRELEASE prefix instruction, or such a write may cause a transaction abort. In addition, recursive locks (when a thread acquires the same lock multiple times without first releasing the lock) can also cause a transaction abort. Note that the software can observe the consequences of invalidated locks acquired in the critical section. Such a read operation returns the value of the write to the lock.

  The processor automatically detects violations of these guidelines and safely transitions to non-transactional execution without invalidation. Since Intel (registered trademark) TSX detects conflicts at the granularity of a cache line, writing to data placed on the same cache line as the invalidated lock requires another logical processor that invalidates the same lock. May be detected as a data race.

Transaction Nest Both HLE and RTM support nested transaction regions. However, a transaction abort restores the state to the operation that initiated the transaction execution, ie, either an HLE-eligible instruction with an outermost XACQUIRE prefix or an outermost XBEGIN instruction. . The processor treats all nested transactions as one transaction.

HLE Nesting and Invalidation The programmer can nest the HLE region to an implementation specified depth of MAX_HLE_NEST_COUNT. Each logical processor internally tracks a nested count, which is not available to software. HLE eligible instructions with the XACQUIRE prefix increment the nested count, and HLE eligible instructions with the XRELEASE prefix decrement it. The logical processor enters transaction execution when the nested count goes from zero to one. The logical processor attempts to commit only when the nested count reaches zero. If the nesting count exceeds MAX_HLE_NEST_COUNT, a transaction abort may occur.

  In addition to supporting nested HLE regions, the processor can also invalidate multiple nested locks. The processor tracks the lock for invalidation and starts with an HLE eligible instruction with the XACQUIRE prefix for that lock and ends with an HLE eligible instruction with the XRELEASE prefix for the same lock. The processor can always keep track of up to MAX_HLE_ELIDED_LOCKS number of locks. For example, if the implementation supports a MAX_HLE_ELIDED_LOCKS value of 2 and the programmer nests 3 HLE identification critical sections (without executing HLE eligible instructions with an intervening XRELEASE prefix on any of the locks, By executing an HLE-eligible instruction with an intervening XACQUIRE prefix on three individual locks), the first two locks are invalidated, but the third lock is not invalidated (but the transaction write Added to the set). However, execution still continues with the transaction. When an XRELEASE is encountered for one of the two revoked locks, subsequent locks acquired via HLE eligible instructions with the XACQUIRE prefix are revoked.

  The processor attempts to commit the HLE execution if all invalidated XACQUIRE and XRELEASE pairs match, the nested count goes to zero, and the lock meets the requirements. If execution cannot be committed atomically, execution transitions to non-transactional execution with no invalidation as if the first instruction did not have the XACQUIRE prefix.

Nesting of RTM The programmer can nest the RTM area up to the MAX_RTM_NEST_COUNT specified by the implementation. The logical processor keeps track of the nested count internally, but this count is not available to software. The XBEGIN instruction increments the nested count, and the XEND instruction decrements the nested count. The logical processor will only try to commit if the nested count goes to zero. If the nesting count exceeds MAX_RTM_NEST_COUNT, a transaction abort occurs.

HLE and RTM Nesting HLE and RTM provide two alternative software interfaces for common transaction execution functions. The behavior of transaction processing is implementation specific if the HLE and RTM are nested within each other, for example, the HLE is inside the RTM or the RTM is inside the HLE. However, in all cases, the implementation maintains the HLE and RTM semantics. Certain implementations may choose to ignore HLE hints when used in the RTM domain, and may cause a transaction abort when the RTM instruction is used in the HLE domain. In the latter case, the processor re-executes the HLE area without actually invalidating, and then executes the RTM instruction, so that the transition from transaction execution to non-transaction execution occurs seamlessly.

Abort Status Definition The RTM uses the EAX register to communicate abort status to software. After an RTM abort, the EAX register has the following definition:

  The EAX abort status for RTM provides only the cause of the abort. This by itself does not code whether an abort or a commit has occurred for the RTM area. The value of EAX may be 0 after an RTM abort. For example, using a CPUID instruction inside an RTM area may cause a transaction abort, but may not meet the requirement to set any of the EAX bits. As a result, the value of EAX may become zero.

RTM Memory Ordering When the RTM successfully commits, all memory operations in the RTM region appear to be performed atomically. Even if no memory operations are performed in the RTM region, the XBEGIN is followed by the XEND, and a successfully committed RTM region has the same ordering semantics as the LOCK prefix instruction.

  The XBEGIN instruction has no fence semantics. However, if the RTM execution aborts, all memory updates from within the RTM area are discarded and are invisible to any other logical processors.

RTM-enabled debugger support By default, any debug exception inside the RTM region will cause a transaction abort, restore architectural state, and redirect control flow to the fallback instruction address with bit 4 set in EAX. . However, the RTM architecture provides additional functionality to allow software debuggers to intercept execution on debug exceptions.

  If both bit 11 of DR7 and bit 15 of IA32_DEBUGCTL_MSR are 1, execution rolls back due to either RTM abort due to debug exception (#DB) or breakpoint exception (#BP), and fallback. Resume from XBEGIN instruction instead of address. In this scenario, the EAX register is also restored at the time of the XBEGIN instruction.

Programming Considerations In general, it is generally assumed that the area specified by the programmer will successfully execute and commit the transaction. However, there is no such guarantee in Intel (R) TSX. Transaction execution may be aborted for various reasons. To take full advantage of transactional features, programmers need to follow certain guidelines to increase the likelihood of a successful commit to executing a transaction.

  This section discusses various events that can cause a transaction abort. The architecture guarantees that updates made within a transaction that later aborts execution will never be visible. Only committed transaction executions initiate architectural state updates. A transaction abort never causes a functional failure and only affects performance.

Instruction Based Considerations The programmer can safely use any instruction inside a transaction (HLE or RTM) and use the transaction at any privilege level. However, some instructions always abort transaction execution, and execution is seamlessly and safely transitioned to a non-transactional path.

In Intel® TSX, most common instructions can be used inside a transaction without causing an abort. Generally, the following operations do not cause an abort in a transaction:
Operations on instruction pointer registers, general purpose registers (GPR) and status lags (CF, OF, SF, PF, AF, and ZF); and
-Operations on the XMM, YMM, and MXCSR registers.

  However, the programmer must be careful when mixing SSE and AVX operations within a transaction area. The transaction may abort due to the mixture of the SSE instruction accessing the XMM register and the AVX instruction accessing the YMM register. Programmers can use string operations with the REP / REPNE prefix in transactions. However, long strings can cause aborts. Further, the use of CLD and STD instructions may cause an abort if they change the value of the DF flag. However, if DF is 1, the STD instruction will not cause an abort. Similarly, if DF is 0, the CLD instruction will not cause an abort.

  Instructions not listed here as causing an abort when used inside a transaction will usually not abort the transaction (for example, but not limited to, MFENCE, LFENCE, SFENCE, RDTSC, RDTSCP, etc.).

The following instruction aborts transaction execution in any implementation.
・ XABORT
・ CPUID
・ PAUSE

Further, in some implementations, the following instructions may always cause a transaction abort. These instructions are not normally expected to be used inside a transaction area. However, programmers should not rely on these instructions to force a transaction abort, because whether these instructions cause a transaction abort is implementation dependent.
Operations on X87 and MMX ™ architectural states. This includes all MMX and X87 instructions, including the FXRSTOR and FXSAVE instructions.
Update of non-status part of EFLAG: CLI, STI, POPFD, POPQQ, CLTS.
Instructions for updating segment registers, debug registers, and / or control registers: MOV for DS / ES / FS / GS / SS, POP DS / ES / FS / GS / SS, LDS, LES, LFS, LGS, MOV for LSS, SWAPGS, WRFSBASE, WRGSBASE, LGDT, SGDT, LIDT, SIDT, LLDT, SLDT, LTR, STR, Far CALL, Far JMP, Far RET, IRET, DRx, MOV for CR0 / CR2 / CR3 / CR4 / CR8. , And LMSW.
-Ring transitions: SYSENTER, SYSCALL, SYSEXIT, and SYSRET.
TLB and cacheable controls: CLFLUSH, INVD, WBINVD, INVLPG, INVPCID, and memory instructions with non-temporary hints (MOVNTDQA, MOVNTDQ, MOVNTI, MOVNTPD, MOVNTPS, and MOVNTQ).
Save processor state: XSAVE, XSAVEOPT, and XRSTOR.
・ Interrupts: INTn, INTO.
IO: IN, INS, REP INS, OUT, OUTS, REP OUTS, and variants.
VMX: VMPTRLD, VMPTRST, VMCLEAR, VMREAD, VMWRITE, VMCALL, VMLAUNCH, VMRESUME, VMXOFF, VMXON, INVEPT, and INVVPID.
SMX: GETSEC.
-UD2, RSM, RDMSR, WRMSR, HLT, MONITOR, MWAIT, XSETBV, VZEROUPPER, MASKMOVQ, and V / MASKMOVDQU.

Runtime Considerations In addition to instruction-based considerations, runtime events may abort transaction execution. This may be due to data access patterns or the implementation capabilities of the micro-architecture. The following list is not a comprehensive description of the causes of all aborts.

  Transaction faults or traps that must be exposed to software are suppressed. When transaction execution aborts, execution transitions to non-transactional execution as if no fault or trap had occurred. If the exception is not masked, the unmasked exception causes a transaction abort and the state appears as if the exception had not occurred.

  Synchronous exception events (#DE, #OF, #NP, #SS, #GP, #BR, #UD, #AC, #XF, #PF, #NM, #TS, #MF, #DB, When # BP / INT3) occurs, transaction execution is not committed, and non-transaction execution may be required. These events are suppressed as if they had not occurred. In the HLE, the non-transactional code path is identical to the transactional code path, so that when the instruction that caused the exception is re-executed to the non-transaction, these events reappear and the associated synchronization event in non-transactional execution Delivered properly. If an asynchronous event (NMI, SMI, INTR, IPI, PMI, etc.) occurs during transaction execution, transaction execution may be aborted and transition to non-transactional execution. Asynchronous events are suspended and processed after the transaction abort has been processed.

  Transactions only support write-back cacheable memory-type operations. If a transaction involves operations of any other memory type, the transaction can always abort. This includes instructions fetching into the UC memory type.

  For the memory access in the transaction area, the access (Accessed) flag and the dirty (Dirty) flag of the page table entry referred to by the processor may need to be set. The behavior of how the processor performs this control is implementation specific. In some implementations, updates to these flags can be made visible externally, even if the transaction area is subsequently aborted. Some Intel (R) TSX implementations may choose to abort the transaction execution if these flags need to be updated. Further, the processor's page table walk may be written to itself, but result in access to an uncommitted state. Some Intel (R) TSX implementations may choose to abort execution of the transaction area in such situations. Nevertheless, the architecture ensures that if the transaction area aborts, the state written to the transaction is architecturally invisible to the behavior of a TLB-like structure.

  Transaction execution of self-modifying code may cause a transaction abort. Even when using the HLE and RTM, the programmer must continue to follow the guidelines recommended by Intel® when writing self-correcting code and cross-correcting code. RTM and HLE implementations typically provide sufficient resources to execute a common transaction area, but constraining the transaction area implementation or making the size unnecessarily large aborts transaction execution, and It may transition to transaction execution. The architecture does not guarantee the amount of resources available for transaction execution, and does not guarantee that transaction execution will always succeed.

  If a conflicting request is made to a cache line accessed in the transaction area, the transaction execution may be prevented from succeeding. For example, the logical processor P0 reads the line A in the transaction area, another logical processor P1 writes the line A (either inside or outside the transaction area), and the writing of the logical processor P1 increases the transaction execution capability of the processor P0. If so, logical processor P0 may abort.

  Similarly, when P0 writes to line A in the transaction area and P1 reads or writes to line A (either inside or outside the transaction area), the access to line A of P1 is the transaction execution capability of P0. Can prevent P0 from aborting. In addition, other coherence traffic may appear as competing requests and cause aborts. These false conflicts may occur, but are considered uncommon. In the above scenario, the conflict resolution policy for determining whether P0 aborts or P1 aborts is implementation specific.

General Transaction Execution Embodiment:
According to [2], which is hereby incorporated by reference in its entirety, there are basically three mechanisms required to implement atomic and isolated transaction areas: versioning, contention. There is detection and contention management.

  In order for a transaction code region to look atomic, all modifications made by that transaction code region must be stored until commit and isolated from other transactions. The system does this by implementing a versioning policy. There are two versioning paradigms: eager and lazy. The eager versioning system stores the newly generated transaction values in place and the previous memory values separately in what is called an undo (undo) log. Lazy versioning systems temporarily store new values in what is called a write buffer and copy them to memory only on commit. In both systems, a cache is used to optimize the storage of new versions.

  Conflicts need to be detected and resolved to ensure that the transaction appears to execute atomically. Two systems, the eager and lazy versioning systems, detect conflicts by implementing either optimistic or pessimistic conflict detection policies. An optimistic system executes transactions in parallel and checks for conflicts only when the transaction commits. The pessimistic system checks for conflicts for each load and store. Like versioning, conflict detection also uses a cache and marks each line as part of a read set, part of a write set, or both. The two systems resolve the conflict by implementing a contention management policy. There are numerous contention management policies, some better suited for optimistic conflict detection and some better suited for pessimistic conflict detection. Some exemplary policies are described below.

  Since each Transaction Memory (TM) system requires both versioning and contention detection, these options are available in four separate TM designs: Eager-Pessimistic (EP), Eager-Optimistic ( Optimistic (EO), Lazy-pessimistic (LP), and Lazy-optimistic (LO). Table 2 briefly describes all four individual TM designs.

  1 and 2 show an example of a multi-core TM environment. FIG. 1 shows a number of TM-compatible CPUs (CPU1 114a, CPU2 114b, etc.) on one die 100 connected to an interconnect 122 under the control of the interconnect controls 120a, 120b. Each CPU 114a, 114b (also known as a processor) caches instruction caches 116a, 116b for caching instructions from memory to be executed and data (operands) at memory locations operated by CPUs 114a, 114b. And a split cache consisting of a data cache 118a, 118b that supports TM for storage. In one implementation, the caches of the dies 100 are interconnected to support cache coherency between the caches of the dies 100. In one implementation, a single cache, rather than a split cache, is used to hold both instructions and data. In one implementation, the CPU cache is at cache level 1 in a hierarchical cache structure. For example, each die 100 can use the shared cache 124 to be shared among all CPUs 114a, 114b on die 100. In another implementation, each die 100 may have access to a shared cache 124 that is shared among all processors on all dies 100.

  FIG. 2 shows details of an exemplary transaction CPU 114, including additionals to support TM. The transaction CPU 114 (processor) may include hardware to support register checkpoints 126 and special TM registers 128. The transaction CPU cache may include the MESI bit 130, tag 140, and data 142 of a conventional cache, as well as, for example, an R bit 132 indicating that a line was read by the CPU 114 during execution of the transaction, A W bit 138 indicating that the line was written by the CPU 114 during execution.

  An important detail for any programmer in any TM system is how non-transactional access interacts with the transaction. By design, transaction access is shielded from each other using the mechanism described above. However, the interaction between the normal non-transactional load and the transaction containing the new value for that address still needs to be considered. In addition, the interaction between the non-transactional store and the transaction that read its address must be considered. These are issues of database concept separation.

  If every non-transactional load and store behaves like an atomic transaction, the TM system is said to implement strong isolation (sometimes called strong atomicity). Thus, non-transactional loads cannot see uncommitted data, and non-transactional stores cause an atomicity violation in any transaction that has read its address. Systems for which this is not the case are said to implement weak isolation, sometimes called weak atomicity.

  Strong separability is often more desirable than weak separability because strong separability is relatively easy to conceptualize and implement. In addition, if the programmer forgets to enclose some shared memory reference in a transaction, a bug arises, and with strong isolation, the programmer sees a non-transactional region that causes an atomicity violation, so the programmer needs a single debug interface. Is often used to detect oversight. A program written in one model may operate differently on another model.

Further, strong separability is often easier to support in hardware TM than weak separability. With strong isolation, transactions can detect non-transactional loads and stores and operate properly because the coherence protocol already manages load and store communications between processors. In order to implement strong isolation in software transaction memory (TM), non-transactional code must be modified to include read and write barriers, thus increasing performance. May be impaired. Although much effort has been expended to remove many unwanted barriers, such techniques are often complex and performance is typically much lower than that of HTMs.

  Table 2 shows the basic design space of the transaction memory (versioning and conflict detection).

Eager-pessimistic (EP)
This first TM design described below is known as Eager-pessimistic. The EP system stores the write set "in place" (hence the name "eager") and, to support rollback, stores the old value of the overwritten line in an "undo log". To be stored. The processor uses the WCache bit 138 and the RCache bit 132 to keep track of the read and write sets and detect contention when receiving a snooped load request. Perhaps the most prominent examples of EP systems in the known literature are LogTM and UTM.

  Starting a transaction in an EP system is very similar to starting a transaction in other systems: tm_begin () takes a register checkpoint and initializes any status registers. EP systems also require undo log initialization, the details of which depend on the log format, but often initialize a log base pointer to a pre-allocated area of thread private memory. And clearing the log boundary register.

  Versioning: In EP, due to the way that eager versioning is designed to work, the state transition (Modified, Exclusive, Shared, and Invalid) codes for MESI 130. The cache line indicator corresponding to the state) remains almost unchanged. Outside the transaction, the state transitions of MESI 130 remain unchanged at all. When reading a line inside a transaction, a standard coherence transition is applied (S (Shared) → S, I (Invalid) → S, or I → E (Exclusive)), and issues a load miss if necessary. , R bit 132 is also set. Similarly, standard transitions are applied to line writes (S → M, E → I, I → M), issuing misses as needed, but also setting the W (Write, Write) bit 138 I do. If the current transaction aborts, the first time a line is written, it loads the old version of the entire line and then writes and saves it to the undo log. The newly written data is then stored "in place" over the old data.

  Conflict Detection: Pessimistic conflict detection looks for conflicts between transactions using misses or coherence messages exchanged during upgrades. If a read miss occurs in the transaction, other processors will receive the load request, but will ignore this request if they do not have the required line. If other processors have the required line non-speculatively or have line R132 (Read, Read), downgrade this line to S, and in some cases, if they have MESI M or E state. If the line has a line, a cache-to-cash transfer is issued. However, if the cache has line W138, a conflict between the two transactions is detected and additional action must be taken.

  Similarly, when a transaction attempts to upgrade a line from shared to modified (during the first write), the transaction issues an exclusive load request that is also used to detect conflicts. If the receiving cache has the line non-speculatively, then the line is invalidated and, in certain cases, an inter-cache transfer (M or E state) is issued. However, if this line is R132 or W138, a conflict is detected.

  Validation: Transactions always have exclusive access to each write set since conflict detection is performed on every load. Therefore, validation does not require any additional work.

  Commit: Since eager versioning stores the new version of the data item in place, the commit process simply clears the W bit 138 and the R bit 132 and discards the undo log.

  Abort: When a transaction rolls back, the original version of each cache line in the undo log must be restored, and the process is called "unrolling" or "applying" the log. This is done during tm_discard () and must be atomic with respect to other transactions. Specifically, the write set must still be used to detect conflicts: this transaction has only the correct version of the line in its undo log, and the requesting transaction has the correct You have to wait for the version to be restored. These logs can be applied using a hardware state machine or a software abort handler.

  Eager-Pessimistic has the following characteristics: Commit is simple and very fast because it is in place. Similarly, validation is a no-op. Pessimistic conflict detection detects conflicts early, thereby reducing the number of "doomed" transactions. For example, if two transactions participate in a Write-After-Read dependency, that dependency is detected instantaneously in pessimistic conflict detection. However, optimistic conflict detection does not detect such conflicts until the writer commits.

  Eager-Pessimistic also has the following characteristics: As mentioned above, when first written to a cache line, the old values need to be written to the log, resulting in extra cache accesses. Aborts are expensive because they require undoing the log. The load must be issued for each cache line in the log, and will probably advance to main memory before proceeding to the next line. Pessimistic conflict detection also prevents the presence of certain serializable schedules.

  In addition, conflicts are handled when they occur, so there is the potential for livelocks and careful contention management mechanisms must be used to ensure forward progress.

Lazy-Optimistic (LO)
Another common TM design is Lazy-optimistic (LO), which stores its write set in a "write buffer" or "redo log" and detects conflicts at commit (still R and Use W bit).

  Versioning: Similar to the EP system, the LO design MESI protocol is implemented outside the transaction. Once inside the transaction, reading the line will cause a standard MESI transition, but will also set the R bit 132. Similarly, writing a line sets the W bit 138 of the line, but the processing of the MESI transition in the LO design is different from that in the EP design. First, in lazy versioning, new versions of the written data are stored in the cache hierarchy until commit, while other transactions can access older versions available in memory or other caches. . To make the old version available, the dirty line (M line) must be invalidated on the first write by the transaction. Second, due to the optimistic conflict detection feature, no upgrade misses are required: since conflict detection is performed at commit, if the transaction has a line in S state, the transaction simply writes to the line and changes the other. It is only necessary to upgrade that line to the M state without communicating with this transaction.

  Conflict Detection and Validation: To verify transactions and detect conflicts, the LO communicates the address of the speculatively modified line to other transactions only when preparing for a commit. In validation, the processor sends a single, possibly large, network packet containing all addresses in the write set. No data is transmitted, but is left in the committer's cache and marked as dirty (M). To keep track of these speculatively modified lines, in order to build this packet without searching the cache for lines marked W, one bit per cache line, the "Store Use a simple bit vector called a "buffer". Other transactions use this address packet to detect conflicts: if the address is found in the cache and R bit 132 and / or W bit 138 are set, a conflict is initiated. If the line is found but neither R132 nor W138 is set, the line is simply invalidated, which is similar to processing an exclusive load.

  In order to support the atomicity of the transaction, these address packets must be processed atomically, ie no two address packets can exist for the same address at the same time. In a LO system, this can be achieved by simply obtaining a global commit token before sending the address packet. However, a two-phase commit by first sending the address packet, collecting the responses, implementing the ordering protocol (perhaps the oldest transaction first), and committing if all responses are satisfied -A scheme can also be used.

  Commit: Once validated, commit does not require any special processing, it simply clears the W bit 138 and R bit 132, and the store buffer. The transaction write has already been marked dirty in the cache, and other cache copies of these lines are invalidated by the address packet. The other processors can then access the committed data through the normal coherence protocol.

  Abort: Rollback is equally easy: these lines can be invalidated because the write set is contained in the local cache, then the W bit 138 and R bit 132, and the store buffer Clear The store buffer allows the W line to be found and invalidated without having to search the cache.

  Lazy-optimistic has the following characteristics: aborts are very fast, do not require additional loads or stores, and only make local changes. There can be more serializable schedules than found in the EP, which allows the LO system to more aggressively infer that transactions are independent, which Can result in high performance. Finally, slower competition detection may increase the likelihood of forward progress.

  Lazy-optimistic also has the following characteristics: Validation takes global communication time in proportion to the size of the write set. A failed transaction can be a waste of work, as conflicts are only detected at commit time.

Lazy-pessimistic (LP)
Lazy-pessimistic (LP) represents a third TM design option located somewhere between EP and LO: store newly written lines in write buffer, but detect conflicts on every access .

  Versioning: Versioning is similar to, but not identical to, that of LO: reading a line sets the R bit 132, writing a line sets the W bit 138, and the store buffer stores the W line in the cache. Used to track. Also, like the LO, the dirty (M) line must be invalidated during the first write by the transaction. However, because conflict detection is pessimistic, a load exclusive must be performed when upgrading a transaction line from I, S to M, which is different from LO.

  Conflict Detection: LP conflict detection operates in the same way as EP: it looks for conflicts between transactions using coherence messages.

  Validation: As in the EP, pessimistic conflict detection ensures that, at any point in time, a running transaction does not conflict with any other running transactions, so the validation is a no-operation is there.

  Commit: As in LO, commit requires no special processing: it simply clears the W bit 138 and R bit 132, and the store buffer.

  Abort: Rollback is also similar to that of LO: simply invalidate the write set using the store buffer, clear the W bit 138 and R bit 132, and the store buffer.

  LP has the following characteristics: Like LO, abort is very fast. As with EP, the use of pessimistic conflict detection reduces the number of "failed" transactions. As with the EP, some serializable schedules are not allowed and contention detection must be performed on every cache miss.

Eager-Optimistic (EO)
The final combination of versioning and conflict detection is Eager-optimistic (EO). EO may be a sub-optimal option for HTM systems: new transaction versions are written in-place, so you must be aware of conflicts when conflicts occur (i.e., when a cache miss occurs). . However, as the EO waits for conflict detection until commit time, these transactions become "zombie", continue execution, waste resources, and abort.

  EO has been found useful in STM and is implemented by Bartok-STM and McRT. The lazy versioning STM needs to check the write buffer on each read to ensure that the latest value is being read. Write buffers are expensive because they are not hardware structures, and therefore prefer write-in-place. Additionally, optimistic conflict detection offers the advantage of performing this operation collectively, as conflict checking is also expensive in STM.

Contention Management Once the system decides to abort the transaction, we have discussed how a transaction rolls back, but since the conflict involves two transactions, it decides which transaction should be aborted, and which You need to consider topics such as how to start and when to retry an aborted transaction. These are topics addressed by contention management (CM), a key component of transaction memory. Various established methods of how the system initiates an abort and which transactions to abort in a conflict are described below.

Contention Management Policy The contention management (CM) policy is a mechanism that determines which transactions involved in a conflict should be aborted and when to retry the aborted transaction. For example, retrying an aborted transaction instantaneously often does not lead to best performance. Conversely, using a back-off mechanism to delay the retry of an aborted transaction, but may result in better performance. The STM is initially working on finding the best contention management policy, and many of the policies outlined below were originally developed for the STM.

  CM policies make use of a number of measures to make decisions, including the age of the transaction, the size of the read and write sets, the number of previous aborts, and the like. Although there are an infinite number of combinations of measures for making such a determination, specific combinations will be roughly described in descending order of complexity.

  To establish some terminology, it should first be noted that in the competition, there are both attackers and defenders. An attacker is a transaction requesting access to a shared memory location. In pessimistic conflict detection, an attacker is a transaction that issues a load or a load exclusive. In optimistic conflict detection, an attacker is a transaction that is to be verified. A defender is a transaction that receives an attacker request in both cases.

  Aggressive CM policies retry either the attacker or the defender instantly and always. In the LO, aggressive means that the attacker always wins, and thus aggressive is sometimes referred to as committer victory. These policies were used for the earliest LO systems. In the case of an EP, the aggressiveness can be either a defender win or an attacker win.

  Resuming a competing transaction immediately in the face of another conflict always causes a waste of work, i.e., the interconnected bandwidth refills cache misses. Polite CM policies use exponential backoff before resuming contention (but can also use linear). To prevent starvation, a situation in which a process does not have the resources allocated by the scheduler, exponential backoff significantly increases the chance of success of the transaction after approximately n retries. Enhance.

  Another approach to conflict resolution is to randomly abort the attacker or defender (a policy called Randomized). These policies can be combined with a randomized backoff scheme to avoid unnecessary contention.

  However, when selecting a transaction to abort, making a random selection may result in aborting a transaction that has completed "many work", which can waste resources. To avoid such waste, the amount of completed work in a transaction can be taken into account when deciding which transaction to abort. One measure of work may be the age of the transaction. Other methods include Oldest, Bulk ™, Size Matters, Karma, and Polka. Oldest is a simple timestamp that aborts the younger transaction in the conflict. Bulk TM uses this scheme. Size Matters is similar to Oldest, but instead of the age of the transaction, the number of read / write words is used as priority, and after a certain number of aborts, it returns to Oldest. Karma is similar and uses the size of the write set as the priority. Next, after backing off for a certain period of time, rollback proceeds. The aborted transaction retains its priority after being aborted (hence the name Karma). Polka is similar to Karma, but instead of backing off for a predetermined amount of time, it backs off more exponentially each time.

  Since aborts waste work, it makes sense to stall the attacker until the defender finishes its transaction for better performance. Unfortunately, these simple schemes easily lead to deadlocks.

  To solve this problem, a deadlock avoidance technique can be used. Greedy uses two rules to avoid deadlocks. The first rule states that if the first transaction T1 has a lower priority than the second transaction T0, or if T1 is waiting for another transaction, T1 will abort on contention with T0. Things. The second rule is that if T1 has a higher priority than T0 and is not waiting, T0 will wait, abort, or start waiting until T1 commits (in this case, the first) Rules apply). Greedy provides some assurance about the deadline for executing a set of transactions. One EP design (LogTM) uses a CM policy similar to Greedy to achieve conservative deadlock avoidance stall.

The exemplary MESI coherency rules provide four possible states in which a cache line of a multiprocessor cache system can exist, ie, four possible states M, E, S, I defined as follows: I do. :
Modified (M): The cache line exists only in the current cache and is dirty. That is, the cache line has been modified from the value in the main memory. At some point in the future, the cache must write data back to main memory before allowing any other reading of the main memory state (no longer valid). The line changes to the Exclusive state due to the write-back.
Exclusive (E): The cache line exists only in the current cache, but is clean. That is, the cache line matches the main memory. A cache line can change to the Shared state at any time in response to a read request. Alternatively, the cache line can change to the modified state when a write is made.
Shared (S): This cache line can be stored in other caches of the machine and indicates "clean". That is, this cache line matches the main memory. The line can be discarded (changed to Invalid state) at any time.
Invalid (I): Indicates that this cache line is invalid (unused).

  For each cache line encoded in addition to or in addition to the MESI coherency bits, a TM coherency status indicator (R132, W138) may be provided. The R132 indicator indicates that the current transaction has read from cache line data, and the W138 indicator indicates that the current transaction has written to cache line data.

  In another aspect of the TM design, the system is designed with a transaction store buffer. "Methods and Apparatus for Reordering and Renaming Memory References in a Multiprocessor Computer System, at least with the name of at least three patents, filed on March 31, 2000, which is incorporated herein by reference in its entirety. A method is taught for reordering and renaming memory references in a multiprocessor computer system having a second processor. The first processor has a first private cache and a first buffer, and the second processor has a second private cache and a second buffer. The method includes, for each of a plurality of gated store requests storing data, received by the first processor, exclusively obtaining a cache line containing the data by the first private cache. And storing the data in the first buffer. When the first buffer receives a load request from the first processor to load the particular data, the particular data is stored in the first buffer based on an in-order sequence of load and store operations. The data is provided to the first processor. When the first cache receives a request to load the predetermined data from the second cache, an error condition is indicated, and if the request to load the predetermined data corresponds to the data stored in the first buffer, at least one of the processors The current state is reset to the previous state.

  One major implementation component of such a transaction memory function is a transaction backup register file to hold the contents of a pre-transaction GR (General Purpose Register), a cache line accessed during the transaction. A cache directory for tracking, a store cache for buffering the store until the end of the transaction, and a firmware routine for performing various complex functions. This section describes the detailed implementation.

IBM zEnterprise EC12 Enterprise Server Embodiment The IBM zEnterprise EC12 Enterprise Server introduces transaction execution (TX) in transaction memory, partially described in Non-Patent Document 3, incorporated herein by reference in its entirety. .

Table 3 shows an exemplary transaction. An abort condition can be encountered in every execution attempt, for example, due to repeated contention with other CPUs, so that a transaction started with TBEGIN is not guaranteed to always complete successfully in TEND. This requires that the program support a fallback path to perform the same operation non-transactionally, for example, by using a conventional locking scheme. This places a significant burden on the programming and software verification team, especially if the fallback path is not automatically generated by a trusted compiler.

  The requirement to provide a fallback path for aborted transaction execution (TX) transactions can be burdensome. Many transactions that operate on shared data structures are short, touching only a few discrete memory locations and using only simple instructions. For these transactions, IBM zEnterprise EC12 introduces the concept of constrained transactions. Under normal conditions, the CPU 114 guarantees that the constrained transaction will eventually complete successfully, even without imposing a hard limit on the number of retries required. A constrained transaction starts with a TBEGINC instruction and ends with a normal TEND. While the implementation of tasks as constrained or unconstrained transactions generally provides very comparable functionality, constrained transactions simplify software development by eliminating the need for a fallback path. IBM's transaction execution architecture is further described in Non-Patent Document 4, which is incorporated herein by reference in its entirety.

  A restricted transaction starts with a TBEGINC instruction. Transactions started with TBEGINC must follow a list of programming constraints. Otherwise, the program uses a non-filterable constraint-violation interruption. As an exemplary constraint, but not limited to, a transaction can execute up to 32 instructions, all instruction text must be within contiguous 256 bytes of memory, the transaction Contains only relative branches pointing forward (i.e., there are no loops or subroutine calls), and a transaction can access up to four aligned octowords in memory (the octoword is 32 bytes). And restrictions on the instruction set to exclude complex instructions such as decimal or floating point arithmetic. Doubly linked list-including many very powerful concepts of atomic compare-and-swap targeting up to four aligned octowords-many common operations such as insert / delete operations The constraints are selected so that the operation can be performed. At the same time, the constraints are conservatively chosen so that future CPU implementations can guarantee the success of the transaction without the need to adjust the constraints, otherwise this would lead to software incompatibilities. is there.

  TBEGINC is mostly based on XBEGIN or IBM (in IBM® TSX) except that there is no floating point register (FPR) control and program interrupt filtering fields and control is considered to be zero. It behaves like XBEGIN on the zEC12 server. When a transaction aborts, the instruction address is returned directly to TBEGINC instead of after the instruction, reflecting immediate retries for the constrained transaction and the absence of the abort path.

  Nested transactions are not allowed in constrained transactions, but if TBEGINC is performed in an unconstrained transaction, it is treated as opening a new unconstrained nesting level, similar to TBEGIN. This can occur, for example, when an unconstrained transaction calls a subroutine that uses a constrained transaction internally.

Since interrupt filtering is implicitly turned off, every exception during a constrained transaction results in an interrupt to the operating system (OS). The successful completion of the final transaction depends on the OS's ability to page in at most four pages touched by any constrained transaction. The OS must also guarantee a time slice long enough to allow the transaction to complete.

  Table 4 shows a constrained transaction implementation of the code in Table 3, assuming that the constrained transaction does not interact with other lock-based code. Thus, a lock test is not shown, but can be added if constrained transactions and lock-based code are mixed.

  In the event of repeated failures, software emulation is implemented using millicode as part of the system firmware. Advantageously, the constrained transaction has the desired properties, since the burden is removed from the programmer.

  The IBM zEnterprise EC12 processor introduced a transaction execution facility. The processor can decode three instructions every clock cycle. That is, a simple instruction is dispatched as a single micro-op (micro operation), and a more complicated instruction is divided into a plurality of micro-ops 232b. The micro-ops (Uops 232b shown in FIG. 3) are written to the integrated publish queue 216, from which they can be published out-of-order. Up to two fixed-point instructions, one floating-point instruction, two load / store instructions, and two branch instructions can be executed per cycle. Global Completion Table (GCT) 232 holds any micro-ops and transaction nesting depths (TND) 232a. The GCT 232 is written in-order at decode time to track the execution status of each micro-op, and completes the instruction when all micro-ops 232b of the oldest instruction group have been successfully executed.

  Level 1 (L1) data cache 240 (FIG. 3) is a 96 KB (kilobyte) 6-way associative cache with a cache line of 256 bytes and a latency of 4 cycles, It is coupled to a private 1MB (megabyte) 8-way associative second level (L2) data cache 268 (FIG. 3) with a 7 cycle use latency penalty for L1 misses. L1 cache 240 (FIG. 3) is the cache closest to the processor, and Ln cache is the cache at the nth cache level. Both the L1 cache 240 (FIG. 3) and the L2 cache 268 (FIG. 3) are of the store through type. The six cores on each central processing unit (CP) chip share a 48 MB third-level store-in cache, and the six CP chips are glass-ceramic multi-chip modules ( Connected to an off-chip 384 MB fourth level cache packaged together on the MCM). Up to four multi-chip modules (MCMs) can be connected to a coherent symmetric multi-processor (SMP) system with up to 144 cores (all cores available to run customer workloads) Not necessarily).

  Coherency is managed by a variant of the MESI protocol. Cache lines can be owned as read-only or exclusive, and L1 240 (FIG. 3) and L2 268 (FIG. 3) are store-through and therefore do not include dirty lines. The L3 and L4 caches are store-in and track the dirty state. Each cache includes all connected lower-level caches.

  The coherency request is called a "cross interrogate" (XI) and is sent hierarchically from a higher level cache to a lower level cache and between L4s. If one core misses L1 240 (FIG. 3) and L2 268 (FIG. 3) and requests a cache line from the local L3, L3 checks whether L3 owns this line and, if necessary, , Send XI to the currently owned L2 268 (FIG. 3) / L1 240 (FIG. 3) under its L3 to guarantee coherency, and then return the cache line to the requestor. If the request also misses L3, L3 sends the request to L4, which enforces coherency by sending XI to all required L3s under that L4 and neighboring L4s. Next, L4 responds to the requesting L3, which forwards the response to L2 268 (FIG. 3) / L1 240 (FIG. 3).

  Due to the rules of inclusion of the cache hierarchy, cache lines are cross-interrogated from lower level caches due to eviction on higher level caches caused by associative overflow from requests to other cache lines. (XI). These XIs may be referred to as “LRU XI”, where LRU means least recently used.

  Referring to yet another type of XI request, Demote-XI transitions cache ownership from exclusive to read-only state, and Exclusive-XI transitions cache ownership from exclusive to invalid state. Transition to. Demote-XI and Exclusive-XI require a response to the original XI sender. The target cache can either "accept" the XI or send a "reject" response if it needs to first evict dirty data before accepting the XI. The L1 cache 240 (FIG. 3) / L2 cache 268 (FIG. 3) is a store-through scheme, but has a store in the store queue that needs to be sent to L3 before downgrading an exclusive state. Can reject demote-XI and exclusive-XI. The rejected XI is repeated by the sender. The Read-only-XI is sent to the cache that owns the line read-only and cannot respond to such XI, so no response is required for such XI. The details of the SMP protocol are similar to those described for IBM z10 by Non-Patent Document 5, which is incorporated herein by reference in its entirety.

Executing Transaction Instructions FIG. 3 illustrates exemplary components of an exemplary CPU. An instruction decode unit (IDU) 208 keeps track of the current transaction nesting depth (TND) 212. When IDU 208 receives a TBEGIN instruction, the nesting depth is incremented, and conversely, it is decremented upon a TEND instruction. The nesting depth is written to GCT 232 for every dispatched instruction. When TBEGIN or TEND is decoded on a speculative path that is later flushed, the nesting depth of IDU 208 is refreshed from the youngest GCT232 entry that is not flushed. The transaction state is also written into the issue queue 216, for consumption by the execution unit, mostly by the load / store unit (LSU) 280. The TBEGIN instruction may specify a transaction diagnostic block (TDB) for recording state information if the transaction aborts before reaching the TEND instruction.

  Similar to nesting depth, IDU 208 / GCU 232 cooperatively tracks access register / floating point register (AR / FPR) modification masks through transaction nesting. That is, once the AR / FPR modification instruction is decoded and the modification mask blocks it, IDU 208 can place an abort request in GCT 232. When the instruction is next-to-complete, completion is blocked and the transaction aborts. If decoded while in a constrained transaction or exceeds the maximum nesting depth, other restricted instructions, including TBEGIN, are processed similarly.

  The outermost TBEGIN is divided into a plurality of micro-ops according to the GR-Save-Mask, and each micro-op 232b is executed by one of the two fixed-point number units (FXU) 220, and a transaction abort is performed. Save the pair of GRs 228 in a special transaction backup register file 224 that is used to later restore the contents of GR 228. TBEGIN also generates a micro-op 232b to perform an accessibility test of the TDB if 1 is specified, and this address is stored in a dedicated register for later use in the case of an abort. You. In decoding the outermost TBEGIN, the TBEGIN instruction address and instruction text are also stored in dedicated registers for potential subsequent abort processing.

  TEND and NTSTG are simple micro-op 232b instructions. NTSTG (non-transactional store) is marked as non-transactional in the publishing queue and is treated like a normal store except that LSU 280 can process it properly. . TEND is a no-operation at run time, and the transaction ends when TEND completes.

  As described above, the instructions within the transaction are marked as such in the issue queue 216, but otherwise executed with little change, and the LSU 280, as described in the next section, Perform an isolation track.

  The decoding is in-order and the IDU 208 constantly monitors the current transaction state and writes it in the issue queue 216 along with all instructions from the transaction, so TBEGIN, TEND, and , Internal and subsequent instruction execution can be performed out-of-order. An effective address calculator 236 is included in LSU 280. It is even possible (though unlikely) to perform TEND first, the entire transaction second, and finally TBEGIN. The program order is restored by the GCT 232 upon completion. Since the general purpose register (GR) 228 can be restored from the backup register file 224, the length of the transaction is not limited by the size of the GCT 232.

  During execution, program event recording (PER) events are filtered based on event suppression controls, and PER TEND events are detected when enabled. Similarly, while in transaction mode, the pseudo-random number generator may have caused a random abort when enabled by the transaction diagnostic control.

Transaction Isolation Tracking The load / store unit keeps track of cache lines accessed during transaction execution and triggers an abort if XI (or LRU-XI) from another CPU conflicts with the footprint. If the competing XI is exclusive or demote XI, the LSU rejects the XI and returns to L3, expecting the transaction to end before L3 repeats the XI. This "stiff-arming" is very useful in high contention transactions. To prevent hang-up when the two CPUs push each other, an XI reject counter is implemented, which triggers a transaction abort when a threshold is met.

  The L1 cache directory 240 is conventionally implemented with a static random access memory (SRAM). In a transaction memory implementation, the valid bits 244 of the directory (64 rows x 6 ways) are moved to a normal logical latch, and two more bits per cache line, a TX-read bit 248 and a TX-dirty bit 252, Be replenished.

  When the new outermost TBEGIN (interlocked to the previous still pending transaction) is decoded, the TX-Read 248 bit is reset. TX-read 248 bits are set at run time by all load instructions marked as "transactional" in the issue queue. Note that this may result in over-marking if the speculative load is performed, for example, on a mispredicted branch path. An alternative to setting the TX-read bit at load completion is too expensive for silicon area because multiple loads can be completed simultaneously and require a large number of read ports on the load queue. there were.

  Stores are performed in the same manner as in non-transactional mode, except that a transaction mark is placed in the store queue (STQ) 260 entry of the store instruction. When data from STQ 260 is written into L1 240 during write back, the TX-Dirty 252 bit in L1 directory 256 is set for the written cache line. Store write-back to L1 240 occurs only after the store instruction has completed, and at most one store is written back per cycle. Before completion and write-back, the load can access the data from STQ 260 by store transfer, and after write-back, CPU 114 (FIG. 2) uses the speculatively updated data in L1 240 Can be accessed. If the transaction is successfully completed, the TX-Dirty bit 252 of all cache lines is cleared, and in STQ 260, the TX-mark of the store that has not been written is also cleared, and the store that is effectively pending is replaced with the normal store. Change to

  When the transaction aborts, all pending transaction stores, even those that have already completed, are invalidated from STQ 260. All cache lines modified by a transaction in L1 240, that is, the TX-Dirty bit 252 turned on and its valid bit turned off, will effectively remove them from the L1 240 cache instantly.

  The architecture requires that the read set and write set separation of a transaction be maintained before completing a new instruction. This separation is ensured by the XI stalling the completion of the instruction at the appropriate time pending. Speculative out-of-order execution is allowed, optimistically assuming that the pending XI is to a different address and does not actually cause a transaction conflict. This design fits very naturally with XI-vs-completion interlocks implemented on conventional systems to ensure the strong memory ordering required by the architecture.

  When L1 240 receives the XI, L1 240 accesses the directory, checks the validity of the address in the interrogated (XI) L1 240, and reads the TX-read bit on the interrogated (XI) line. If 248 is active and XI is not rejected, LSU 280 will trigger an abort. When a cache line with an active TX-read bit 248 is taken from L1 240 to Least Recently Used (LRU), a special LRU extension vector is created for each of the 64 rows of L1 240 with a TX-read on that row. Remember that the line existed. Since there is no exact address tracking for the LRU extension, any non-rejected XI will hit a valid extension row and the LSU 280 will trigger an abort. Provided that contention with other CPUs 114 (FIG. 2) for inaccurate LRU extension tracking does not cause an abort, providing LRU extensions effectively improves read footprint capability and associativity from L1 size to L2 size.

  The store footprint is limited by the store cache size (store cache is described in more detail below), and thus implicitly by L2 size and associativity. If a TX-dirty cache line is LRU processed from L1, there is no need to perform an LRU extension action.

Store Cache In conventional systems, since L1 240 and L2 268 are store-through caches, all store instructions cause an L3 store access, and now there are six cores per L3, and the performance of each core is Further improved, the store speed for L3 (and to a lesser extent L2) becomes a problem for certain workloads. To avoid store queuing delays, it is necessary to add a collection store cache that combines the store with a neighboring address before sending the store to L3.

  For transaction memory performance, invalidate any TX-Dirty cache line from L1 240 upon transaction abort, as L2 cache 268 will return a clean line sooner (7 cycle L1 miss penalty). Is acceptable. However, in terms of performance (and silicon area for tracking), the transaction store is forced to write L2 268 before the transaction is completed, and then all dirty L2s at abort (or worse, with shared L3) Invalidating cache lines is not acceptable.

  Both issues of store bandwidth and transactional memory store processing can be addressed with the collection store cache 264. The cache 264 is a 64-entry circular queue, with each entry holding 128 bytes of data with byte-precise valid bits. In a non-transactional operation, upon receiving a store from LSU 280, store cache 264 checks if an entry with the same address exists, and if so, gathers the new store into the existing entry. If no entry exists, a new entry is written to the queue, and if the number of free entries falls below the threshold, the oldest entry is written back to the L2 cache 268 and L3 cache.

  When the new outermost transaction begins, all existing entries in the store cache 264 are marked as closed so that the new store cannot be collected there, and eviction of these entries to L2 268 and L3 begins. Is done. From that point on, the transaction store from LSU 280 STQ 260 allocates new entries or aggregates with existing transaction entries. Write-back of these stores to L2 268 and L3 will be blocked until the transaction is successfully completed, at which point the later (post-transaction) store will wait until the next transaction closes their entries again. , Can continue to be collected in existing entries.

  The store cache 264 is queried on every exclusive XI or demote XI, causing a rejection of the XI if the XI is compared to any active entry. If the core does not complete further instructions while continuously rejecting XI, the transaction is aborted at a certain threshold to avoid hang-up.

  When the store cache overflows, LSU 280 requests a transaction abort. LSU 280 detects this condition when attempting to send a new store that cannot be merged with an existing entry, and the entire store cache 264 is filled with stores from the current transaction. Store cache 264 is managed as a subset of L2 268, and dirty lines can be transactionally evicted from L1 240, but they must reside in L2 268 throughout the transaction. Thus, the maximum store footprint is limited to a store cache size of 64 × 128 bytes, and is also limited by L2 268 associativity. L2 268 is 8-way associative and has 512 rows, so it is generally large enough to not cause a transaction abort.

  If the transaction aborts, the store cache is notified and all entries holding transaction data are invalidated. The store cache also has a mark every 1 doubleword (8 bytes) whether the entry was written by the NTSTG instruction-these doublewords remain valid over the transaction abort.

Features of Millicode Implementation Traditionally, IBM mainframe server processors include a layer of firmware called millicode that performs complex functions such as specific CISC instruction execution, interrupt handling, system synchronization, and RAS. . Millicode includes machine dependent instructions and instruction set architecture (ISA) instructions fetched and executed from memory as well as application program and operating system (OS) instructions. Firmware resides in a restricted area of main memory that is not accessible to customer programs. When the hardware detects a situation in which millicode needs to be called, the instruction fetch unit 204 switches to "millicode mode" and starts fetching at the appropriate location in the millicode memory area. Millicode can be fetched and executed in the same manner as Instruction Set Architecture (ISA) instructions, and can include ISA instructions.

  With respect to transaction memory, millicode is involved in a variety of complex situations. Every transaction abort calls a dedicated millicode subroutine to perform the required abort operation. The transaction abort millicode begins by reading a special purpose register (SPR) that holds the abort cause, potential exception cause, and the aborted instruction address inside the hardware, and then uses the millicode. If 1 is specified, the TDB is stored. The TBEGIN instruction text is loaded from the SPR to get the GR preservation mask needed to know which GR 228 the millicode restores.

  The CPU 114 (FIG. 2) supports special millicode-specific instructions for reading backup GRs and copying them to the main GR. The TBEGIN instruction address is also loaded from the SPR, and once the Millicode Abort subroutine is completed, a new instruction address is set in the PSW to continue execution after TBEGIN. This PSW can later be saved as a program-old PSW if the abort was caused by an unfiltered program interrupt.

  The TABORT instruction may be implemented in millicode, i.e., when the IDU 208 decodes the TABORT, the TABORT instruction instructs the instruction fetch unit to branch to the TABORT millicode, from which the millicode is sent to the common abort.・ Branch to subroutine.

  The Extract Transactional Nesting Depth (ETND) instruction is also not performance critical and can therefore be millicoded. That is, the millicode loads the current nesting depth from a special hardware register and places it into GR228. PPA instructions can be millicoded. The PPA instruction implements an optimal delay based on the current abort count provided by software as an operand to the PPA, as well as other hardware internal states.

  For constrained transactions, the millicode can constantly monitor the number of aborts. The counter is reset to 0 when TEND completes successfully or when an interrupt to the OS occurs (it is not known whether the OS returns to the program or when the OS returns to the program). . Depending on the current abort count, the millicode can call a specific mechanism to increase the likelihood of a successful retry of a later transaction. This mechanism can be caused, for example, by continuously increasing the random delay between retries and by reducing the amount of speculative execution, caused by speculative access to data that the transaction is not actually using. Avoiding encountering an abort. As a last resort, before releasing the other CPU and continuing with normal processing, broadcast the millicode to the other CPU to stop all conflicting work and retry the local transaction. it can. Some serialization between millicode instances on different CPUs is required because multiple CPUs need to be coordinated to avoid deadlocks.

  Referring now to FIG. 4, reference numeral 400 generally indicates an exemplary embodiment in which a method for adaptive sharing of data may be implemented in hardware or software.

ＨＬＥは、前述のように、従来のロック・コードを使用するように書かれたプログラムが、トランザクション実行を実装するハードウェアを利用する機会を可能にする。しかしながら、高競合状態のメモリ領域においては、競合が発生した場合、プロセッサは、トランザクションをアボートし、悲観的ロック挙動を用いてクリティカル・セクションを再び実行することができる。一実施形態においては、キャッシュラインをまたぐいずれのロックも無効化することができず、ＨＬＥなしに再実行を自動的にトリガする。従って、クリティカル・セクションが常にトランザクションとして失敗することが分かっている場合、トランザクション実行にデフォルト設定し、その後、ロックを用いて成功裏に再開させることは、性能を低下させることがある。 In current implementations, two approaches to synchronizing data access based on locks can be implemented conventionally. In locking data structures, also called locking or true locking, when a program wants to guarantee exclusive access to a memory area, also called shared data, during a critical section of code. There is. In this case, the program can protect the shared data with a lock that acts like a flag to competing programs for which no shared data is available at this time. However, the locking mechanism can strictly control access to shared data. In a memory area in a low contention state, a competing program may wait unnecessarily, adversely affecting performance. For example, in the following code sample, two threads are updating different parts of the structure, and even if they execute in parallel, thread 2 waits for execution while thread 1 holds a lock on the structure hash_tbl.

HLE, as described above, allows programs written to use conventional locking code to take advantage of hardware that implements transaction execution. However, in memory areas with high contention, if a contention occurs, the processor can abort the transaction and re-execute the critical section using pessimistic locking behavior. In one embodiment, any locks across cache lines cannot be invalidated and automatically trigger a re-run without HLE. Thus, if a critical section is known to always fail as a transaction, defaulting to transaction execution and then successfully restarting with locks can degrade performance.

  At 410, when the processor or CPU 114 (FIG. 2) initiates a code sequence to access a memory area, the CPU 114 (FIG. 2) causes the contention predictor (ie, CPU) to be implemented in either hardware or software. , HLE Predictor or Hardware Lock Virtualizer) to attempt to predict if lock invalidation could succeed or if locks should be used instead. In operation, as described below, the contention predictor can operate in various hardware and software environments. However, where a conflict predictor refers to an embodiment of a conflict prediction in an HLE environment, the conflict predictor may also be referred to as an HLE predictor. In one embodiment, a simple count of successful transaction executions can be kept, for example, in hardware registers or memory locations for each thread, or can be shared for all threads. Beyond the threshold representing the count of successful transaction executions, at 410, due to the low likelihood of interference, the contention predictor indicates that the transaction execution path, i. It can be expected that it can be effective. In at least one embodiment, the counter is initially initialized to favor the more effective execution path, and in at least one embodiment, preferably corresponds to transaction execution based on lock invalidation. In another embodiment, the estimated relative cost of executing a transaction for acquiring and executing a lock can be calculated in hardware or with instructions inserted into the program stream. Based on the calculated relative costs, the conflict predictor predicts that the transactional or non-transactional path is more effective, for example, because the predicted path is less expensive to execute or less likely to encounter interference. can do. In another embodiment, the compiler may implicitly insert a behavior hint into the contention predictor and select either the transaction execution path at 420 or the lock path at 455 at 410. CPU 114 (FIG. 2) may begin executing the critical section as a transaction at 420 and may update data at 425 as needed. At the end of the transaction at 430, but before committing the result, the CPU 114 (FIG. 2) determines at 435 the interference that caused the transaction to abort (ie, two or more code sequences were executed in parallel on the same data). Operating) is detected. If no interference is detected, at 440, the transaction can successfully commit the result, which can then be used by other transactions. However, if CPU 114 (FIG. 2) detects the interference at 435, execution resumes at 455 using the lock. At 460, the critical section must explicitly acquire a lock that protects the memory area being accessed. However, a lock requester may be made to wait until a lock is released by a competing process in an action called spinning. Finally, when the lock is obtained at 460, the critical section can continue processing. At 470, once the data protected by the lock has been updated, the critical section is complete and the lock can be released at 475.

  Referring to FIG. 5, reference numeral 500 generally illustrates an exemplary embodiment in which a contention predictor (ie, a hardware lock virtualizer) is implemented in an environment where HLE support is present. As described above, HLE is a legacy compatible instruction set extension of Intel, including XACQUIRE and XRELEASE, which allows programs written to use traditional locking code to execute the code substantially. Enables the opportunity to utilize hardware that implements transaction execution without the need for local modifications. In this embodiment, the HLE predictor is a specific example of Intel® HLE.

  At 505, the CPU 114 (FIG. 2) executes the Intel® XACQUIRE prefix instruction to start the HLE sequence with the associated lock acquisition transaction. In one embodiment, the sequence may be represented as XACQUIRE followed by a lock acquisition transaction. In some implementations, the XACQUIRE prefix can be ignored. In other implementations, the XACQUIRE sequence can be selectively implemented. Following the start of the HLE start sequence, at 510, the conflict predictor, the HLE predictor, is called. Based on the prediction, lock invalidation can be performed or a lock can be obtained. Having made the prediction between lock invalidation and lock acquisition, processing can proceed substantially similar to that described at 420-475 in FIG.

  Referring to FIG. 6, reference numeral 600 generally designates for adaptive sharing of data with a selection between lock invalidation and lock according to an exemplary embodiment in which there is no additional hardware facility. FIG. 2 shows a flow diagram of the method. In this exemplary embodiment, hints to the contention predictor may be provided, for example, through the operating system or by hardware, in the code stream of the application program. For example, in one embodiment, a programmer may explicitly insert one or more instructions, or a compiler may implicitly insert behavior hints into a conflict predictor. The contention predictor may maintain a history vector or count to track the number of both successful and unsuccessful predictions, i.e., misprediction, over a period of time, e.g., one second. Next, at 610, the contention predictor can compare the misprediction count to a threshold number of failures during the time window. If the misprediction exceeds the threshold number of failures during the time window, the contention predictor can default to performing with locks, ie, non-transactional mode, for the remainder of the time window. During the time window, the memory area may be in a high contention state due to workload characteristics, for example, when multiple transactions update competing data simultaneously. By temporarily choosing a lock as the default, the contention predictor can avoid the possibility of having to restart a failed transaction and improve throughput by avoiding a transaction abort. However, once the time window has expired, the contention of the memory region may have relaxed and the contention predictor may attempt to execute the transaction again. In one embodiment, the contention predictor is implemented in software, and the decision whether to perform lock invalidation or lock enforcement is made by a software-implemented algorithm that uses a first version of code that implements lock invalidation. Or by passing control to a second version of the code that implements lock acquisition. In other embodiments, the decision 610 is based on the history of interference and reflects expected interference or non-interference associated with a field that is the target of the update transaction in response to an instruction to update a particular entry by software. And implemented using alternative tests.

  At 655, the critical section must explicitly acquire a lock that protects the memory area being accessed. However, a lock requester may have to wait until a lock is released by a competing process in an action called spin. Upon finally acquiring the lock at 660, the critical section can continue processing. Once the data protected by the lock is updated at 670, the critical section is completed at 675 and the lock can be released. At 680, CPU 114 (FIG. 2) can check for expiration of the time window. If the time window has not expired, then, at 680, the process ends. However, if the time window has expired, then at 685, reset the count of failed and successful transaction executions, effectively reset the time window, and begin retraining the contention predictor. Can be.

  If the misprediction does not exceed the threshold number of failures during the time window, then at 610, the contention predictor combines the lock with an HLE transaction or with an explicit read of the lock word rather than a lock acquisition. Transaction to implement lock invalidation. When selected to execute as an HLE transaction (or as a transaction that implements lock invalidation in conjunction with a software transaction that performs lock invalidation by executing a transaction that includes the lock word in the read set), At 615, CPU 114 (FIG. 2) can increment the count of successful transaction executions. The HLE transaction at 620 can update the data at 625 as needed. After the end of the transaction at 630, but before committing the result at 635, the CPU 114 (FIG. 2) may execute the abort of the transaction (ie, two or more code sequences operate in parallel on the same data). Is detected). If no interference is detected, at 640, the HLE transaction (or other transaction that implements lock invalidation) can successfully commit the result, which can then be used by other processes. However, if the CPU 114 (FIG. 2) detects the interference at 635, the failed transaction is counted as a misprediction, and this is used to train the conflict predictor to make the conflict predictor's future prediction more accurate. At 650, the count of failed transaction executions is incremented. At 655 and 660, CPU 114 (FIG. 2) can now acquire a lock on the memory area and attempt to resume the critical section non-transactedly, ie, with the lock. Once the data protected by the lock is finally updated at 670, processing of the critical section is complete and the lock can be released at 675. At 680, CPU 114 (FIG. 2) can check for expiration of the time window. If the time window has not expired, then the process ends at 680. However, if the time window has expired, then the failed transaction execution and successful transaction execution counts can be reset at 685, effectively retraining the contention predictor.

  Referring now to FIG. 7, reference numeral 700 generally designates an exemplary embodiment in which a method for adaptive sharing of data may include a monitoring facility in hardware when a lock is enforced. FIG. In FIG. 7, the processing of the HLE transaction, 710-750, is substantially similar to the way the embodiment of FIG. 6 processes the HLE, 610-650. However, FIG. 7 introduces a hardware lock monitoring facility for paths where critical sections are executed non-transactionally. In this embodiment, the hardware lock monitoring facility returns the result as if the critical section was actually executed as an HLE transaction while the critical section allowed execution in the locked memory area. Attempts to minimize misprediction by making predictions. Upon successfully acquiring the lock at 760 and 765, at 770, the hardware lock monitoring facility may begin monitoring the status of the lock. At 775, the critical section updates the data in the locked memory area, and at 780, terminates execution by releasing the lock. However, during execution, if the hardware lock monitoring facility at 785 detects that another process has checked the status of the lock flag, and then detected that this critical section was executing as a transaction rather than non-transactional Access attempted by other processes has resulted in interference and transaction failure. In one embodiment, only locks are monitored. In another embodiment, updated data is monitored as part of the locked area. As a result, at 790, the hardware lock monitoring facility can increment the count of failed transaction executions.

  In another embodiment, the hardware lock monitoring facility may monitor all data access attempts within the locked memory area. If another process attempts to access data in this area, then, at 790, the hardware lock monitoring facility may count this as interference and potential transaction failure. Thus, the contention predictor can learn to more accurately predict whether transactional execution or non-transactional execution is more likely to succeed.

  In another embodiment, at 750, a restart flag may be set when the transaction execution failure count is incremented. Next, at 755, the restart flag may be reset when the count of successful transaction executions has been incremented. The resume flag prevents the count of failed transaction executions from being incremented twice: once upon failure, such as an HLE transaction at 750, and once upon resumption with a lock at 755. The prediction accuracy can be improved.

  Referring now to FIG. 8, in one embodiment, in a Hardware Lock Elimination (HLE) environment, predicting 810 whether the HLE transaction actually acquires the lock and should execute non-transactionally. , Based on encountering the HLE lock-acquire instruction, determining whether to invalidate the lock and proceed as an HLE transaction or acquire the lock and proceed as a non-transaction based on the HLE predictor 820; , Set the address of the lock as a read set for the HLE transaction, inhibit any write to the lock by lock-acquire instructions, and release the lock based on the prediction that the HLE predictor will invalidate. The HLE lock-acquire instruction is based on 830 proceeding in HLE transaction execution mode until a H.lease instruction is encountered or an HLE transaction encounters a transaction conflict and the HLE predictor predicts that no invalidation will be performed. 840 as a non-HLE lock-acquire instruction and proceed in non-transactional mode 840.

  Referring now to FIG. 9, in one embodiment, updating the HLE predictor is based on a successful prediction of the HLE 910. Based on the first encounter of an HLE transaction with a lock address, the count of successful HLE transaction executions associated with the lock address is initialized to zero, completing any subsequent HLE transactions with the lock address. Based on this, the HLE predictor increments the count of failed HLE transaction executions associated with the lock address of the HLE transaction, where a high count indicates a high likelihood of abort 920. In non-transactional mode, monitor attempts to access the lock by another process and increment 950 the count of failed HLE transactions when an attempt by another process is detected. Tracking the count of successful HLE transaction executions and the count of failed HLE transaction executions within the time window, and based on the count of failed HLE transaction executions exceeding a failure threshold number, the non-transactional mode for the remainder of the time window 970 to default. Based on the expiration of the time window, the count of successful HLE transaction executions and the count of failed HLE transaction executions are reset 960 to zero.

  Referring now to FIG. 10, a computing device 1000 can include a respective set of internal components 800 and external components 900. Each of the set of internal components 800 includes one or more processors 820 on one or more buses 826, one or more computer readable RAMs 822, and one or more computer readable ROMs; Operating system 828; one or more software applications that perform the methods of FIGS. 5-7; and one or more computer-readable tangible storage devices 830. The one or more operating systems are each configured for execution by one or more of respective processors 820 via one or more of respective RAMs 822 (generally including cache memory). Stored on one or more of the computer-readable tangible storage devices 830. In the embodiment shown in FIG. 10, each of the computer-readable tangible storage devices 830 is an internal hard drive magnetic disk storage device. Alternatively, each of the computer readable tangible storage devices 830 may be a semiconductor storage device such as a ROM 824, an EPROM, a flash memory, or any other computer readable tangible storage capable of storing computer programs and digital information. It is a storage device.

  Each set of internal components 800 may also include one or more computers, such as thin-provisioned storage devices, CD-ROMs, DVDs, SSDs, memory sticks, magnetic tapes, magnetic disks, optical disks, or semiconductor storage devices. Also includes an R / W drive or interface 832 for reading from and writing to the readable tangible storage device 936. R / W drive or interface 832 is used to load device driver 840 firmware, software, or microcode into tangible storage device 936 to facilitate communication with components of computing device 1000. be able to.

  Each set of internal components 800 also includes a network adapter (or switch port) such as a TCP / IP adapter card, a wireless WI-FI interface card, or a 3G or 4G wireless interface card, or other wired or wireless communication link. Card) or interface 836. An operating system 828 associated with the computing device 1000 is connected to an external computer (eg, a server) via a network (eg, the Internet, a local area network, or a wide area network) and respective network adapters or interfaces 836. ) Can be downloaded to the computing device 1000. From a network adapter (or switch port adapter) or interface 836, an operating system 828 associated with the computing device 1000 is loaded into the respective hard drive 830 and network adapter 836. A network may include copper wires, fiber optics, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers.

  Each set of external components 900 may include a computer display monitor 920, a keyboard 930, and a computer mouse 934. External components 900 may also include a touch screen, virtual keyboard, touch pad, pointing device, and other human interface devices. Each set of internal components 800 may also include a device driver 840 for interfacing to a computer display monitor 920, a keyboard 930, and a computer mouse 934. Device driver 840, R / W drive or interface 832, and network adapter or interface 836 include hardware and software (stored in storage device 830 and / or ROM 824).

  Various embodiments of the present disclosure are implemented in a data processing system suitable for storing and / or executing program code that includes at least one processor coupled directly or indirectly to a memory element through a system bus. can do. The memory elements may include, for example, local memory used during the actual execution of the program code, mass storage, and at least some of the code to reduce the number of times code must be retrieved from the mass storage during execution. A cache that temporarily stores program code. Including memory.

  Input / output or I / O devices (including but not limited to keyboards, displays, pointing devices, DASDs, tapes, CDs, DVDs, thumb drives and other memory media, etc.) directly or It can be coupled to the system through an intervening I / O controller. A network adapter may be coupled to the system to allow the data processing system to become coupled to another data processing system or a remote printer or storage device through an intervening private or public network. Modems, cable modems and Ethernets are just a few of the available types of network adapters.

  The invention can be a system, method, and / or computer program product. The computer program product may include computer readable storage medium (s) having computer readable program instructions thereon for causing a processor to implement aspects of the invention.

  The computer-readable storage medium may be a tangible device capable of holding and storing instructions used by the instruction execution device. The computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above. Can be. A non-exhaustive list of more specific examples of computer readable storage media includes: portable computer diskette, hard disk, random access memory (RAM), read only memory (ROM), Erasable programmable read only memory (EPROM or flash memory), static random access memory (SRAM), portable, compact disk read only memory (CD-ROM), digital versatile disk (DVD), memory -Mechanical encoding devices, such as sticks, floppy disks, punch cards or raised structures in grooves with instructions recorded thereon, and suitable combinations of any of the above. As used herein, a computer-readable storage medium is a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (eg, an optical pulse through a fiber optic cable), or It should not be interpreted as a transient signal itself, such as an electrical signal transmitted over wiring.

  The computer readable program instructions described herein may be transmitted from a computer readable storage medium to a respective computer computing / processing device or to a network such as, for example, the Internet, a local area network, a wide area network, and / or a wireless network. Via an external computer or an external storage device. The network may include copper transmission cables, optical transmission cables, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer readable program instructions from the network and stores the computer readable program instructions in a computer readable storage medium in the respective computing / processing device. Transfer instructions.

  The computer readable program instructions for performing the operations of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, millicode, firmware instructions, state setting data, or Java, Smalltalk, C ++. And source written in any combination of one or more programming languages, including an object-oriented programming language such as, and a conventional procedural programming language such as the "C" programming language, or a similar programming language. -Can be either code or object code. The computer readable program instructions may execute entirely on the user's computer, or may run partially on the user's computer and partially run on the user's computer as a standalone software package. It may be executed and partly executed on a remote computer, or completely executed on a remote computer or server. In the last scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or wide area network (WAN), or a connection to an external computer (Eg, through the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may be a computer to implement aspects of the present invention. By personalizing the electronic circuit with the status information of the readable program instructions, the computer readable program instructions can be executed.

  Aspects of the invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

  These computer readable program instructions are provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing device to produce a machine, and thereby are executed by the processor of a computer or other programmable data processing device. The instructions may create a means for implementing the specified function / operation in one or more blocks of the flowcharts and / or block diagrams. These computer readable program instructions are stored in a computer readable medium capable of directing a computer, programmable data processor, and / or other device to function in a particular manner, whereby the instructions are stored internally. The computer-readable storage medium on which is stored manufactures products that include instructions that implement the specified functions / acts in one or more blocks of the flowcharts and / or block diagrams.

  Loading computer program instructions onto a computer, other programmable data processing device, or other device to cause a series of operating steps to be performed on the computer, other programmable data processing device, or other device; Generates a computer-implemented process whereby instructions executed on a computer or other programmable device or other device cause instructions / functions specified in one or more blocks of flowcharts and / or block diagrams to occur. It can also provide a process for performing the action.

  The flowcharts and block diagrams in the drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions that includes one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially simultaneously, or sometimes the blocks may be executed in the reverse order, depending on the function involved. Also, each block in the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be performed by dedicated hardware-based systems that perform designated functions or operations, or Note also that it can be implemented in combination with computer instructions.

  While preferred embodiments have been shown and described in detail herein, it will be apparent to those skilled in the art that various modifications, additions, substitutions, and the like can be made without departing from the spirit of the disclosure. Accordingly, they are considered to be within the spirit of the present disclosure as defined in the following claims.

100: die 114a, 114b: CPU
116a, 116b: instruction caches 118a, 118b: data caches 120a, 120b: interconnection control 122: interconnection 124: shared cache 126: register checkpoint 128: special TM register 130: MESI bit 132: R bit 138: W Bit 140: Tag 142: Data 204: Instruction fetch unit 208: Instruction decode unit (IDU)
212: Transaction nesting depth (TND)
216: Issue queue 220: Fixed point number unit (FXU)
224: Backup register file 228: General-purpose register (GR)
232: Global Completion Table (GCT)
232a: Transaction nesting depth (TND)
232b: micro-op (Uop)
236: address calculator 240: L1 data cache 244: valid bit 248: TX-read bit 252: TX-dirty bit 256: L1 directory 260: store queue (STQ)
264: Collection store cache 268: L2 data cache 280: Load / store unit (LSU)
800: Internal component 820: Processor 822: Computer readable RAM
824: Computer readable ROM
826: Bus 828: Operating system 830, 936: Computer readable tangible storage device 832: R / W drive or interface 836: Network adapter or interface 840: Device driver 900: External component 920: Computer display monitor 930 : Keyboard 934: computer mouse 1000: computing device

Claims (20)

In a Hardware Lock Elimination (HLE) environment, a method for an HLE transaction to actually acquire a lock and predictively determine whether to execute non-transactionally,
Based on encountering an HLE lock-acquire instruction to execute an HLE transaction, invalidate the lock and proceed as an HLE transaction or acquire the lock and proceed as a non-transaction based on an HLE predictor. To determine
Based on the prediction that the HLE predictor will perform the invalidation, set the address of the lock as a read set of the HLE transaction, inhibit any write to the lock by the lock-acquire instruction, and release the lock. Proceeding in an HLE transaction execution mode until an xrelease instruction is encountered or the HLE transaction encounters a transaction conflict;
Treating the HLE lock-acquire instruction as a non-HLE lock-acquire instruction based on predicting that the HLE predictor will not perform the invalidation and proceeding in a non-transactional mode;
Only containing the HLE predictor takes into account the success of the prediction was not performed prior the revocation relating to the lock, to predict whether not to perform the said disabling or performing invalidation method .   Updating the HLE predictor based on a successful prediction of the HLE transaction, the HLE predictor further comprising: predicting and updating whether the HLE transaction is likely to abort; The method of claim 1. Initializing a count of successful HLE transaction executions associated with the address of the lock to zero based on the first encounter of an HLE transaction with the address of the lock;
Incrementing a count of failed HLE transaction executions associated with the address of the lock of the HLE transaction in the HLE predictor based on aborting any subsequent HLE transaction having the address of the lock. Increasing the count of failed HLE transaction executions indicates a high probability of an abort, said incrementing;
Incrementing the count of successful HLE transaction executions associated with the address of the lock of the HLE transaction in the HLE predictor based on completing any subsequent HLE transaction having the address of the lock;
Further seen including, wherein whether to disable or not to perform invalidation prediction, the are successful HLE considering the count of the count and the failed HLE transaction execution of transaction execution performed, according to claim 1 or 3. The method according to 2. Monitoring non-transactional mode for attempts to access the lock by another process;
Incrementing the count of the failed HLE transaction executions upon detecting the access attempt by the another process;
4. The method of claim 3, further comprising: Tracking the count of the successful HLE transaction executions and the count of the failed HLE transaction executions within a time window;
Comparing the count of failed HLE transaction executions to a threshold number of failures during the time window;
Defaulting to a non-transactional mode for the remainder of the time window based on the count of failed HLE transaction executions exceeding the failed threshold number;
The method according to claim 3, further comprising:   The method of claim 5, further comprising resetting the count of successful HLE transaction executions and the count of failed HLE transaction executions to zero based on expiration of the time window. In a hardware lock elimination (HLE) environment, a computer program for an HLE transaction to actually acquire a lock and predictively determine whether to execute non-transactionally, said computer program comprising: ,
Based on encountering an HLE lock-acquire instruction to execute an HLE transaction, invalidate the lock and proceed as an HLE transaction or acquire the lock and proceed as a non-transaction based on an HLE predictor. To determine
Based on the prediction that the HLE predictor will perform the invalidation, set the address of the lock as a read set of the HLE transaction, inhibit any write to the lock by the lock-acquire instruction, and release the lock. Proceeding in an HLE transaction execution mode until an xrelease instruction is encountered or the HLE transaction encounters a transaction conflict;
Treating the HLE lock-acquire instruction as a non-HLE lock-acquire instruction based on predicting that the HLE predictor will not perform the invalidation and proceeding in a non-transactional mode;
The HLE predictor determines whether to perform the invalidation or the invalidation in consideration of the success or failure of the prediction that the previous invalidation for the lock was not performed. A computer program that makes predictions .   Updating the HLE predictor based on a successful prediction of the HLE transaction, wherein the HLE predictor further performs predicting and updating whether the HLE transaction is likely to abort. A computer program according to claim 7, for executing the program. Monitoring non-transactional mode for attempts to access the lock by another process;
Incrementing a count of failed HLE transaction executions associated with the address of the lock upon detecting the access attempt by the another process;
The computer program according to claim 7, further causing the computer program to execute. Monitoring, in non-transactional mode, attempts by another process to access the memory area protected by the lock;
Incrementing a count of failed HLE transaction executions associated with the address of the lock upon detecting the access attempt by the another process;
The computer program according to any one of claims 7 to 9, further causing the computer program to execute. Initializing a count of successful HLE transaction executions associated with the address of the lock to zero based on the first encounter of an HLE transaction with the address of the lock;
Incrementing a count of failed HLE transaction executions associated with the lock address of the HLE transaction in the predictor based on aborting any subsequent HLE transaction having the address of the lock, A high count of failed HLE transaction executions indicating a high probability of an abort, said incrementing;
Incrementing the count of successful HLE transaction executions associated with the address of the lock of the HLE transaction in the HLE predictor based on completing any subsequent HLE transaction having the address of the lock;
The prediction of whether to perform the invalidation or not to perform the invalidation is performed in consideration of the count of the successful HLE transaction execution and the count of the failed HLE transaction execution. computer program according to any one of claims 7 to 10. Tracking the count of the successful HLE transaction executions and the count of the failed HLE transaction executions within a time window;
Comparing the count of failed HLE transaction executions to a threshold number of failures during the time window;
Defaulting to a non-transactional mode for the remainder of the time window based on the count of failed HLE transaction executions exceeding the failed threshold number;
12. The computer program according to claim 11, further causing the computer program to execute.   13. The computer program of claim 12, further comprising resetting the count of successful HLE transaction executions and the count of failed HLE transaction executions to zero based on expiration of the time window. In a Hardware Lock Elimination (HLE) environment, a computer system for an HLE transaction to actually acquire a lock and predictively determine whether to execute non-transactionally, said computer system comprising:
Memory and
A processor in communication with the memory; and
Based on encountering an HLE lock-acquire instruction to execute an HLE transaction, invalidate the lock and proceed as an HLE transaction or acquire the lock and proceed as a non-transaction based on an HLE predictor. To determine
Based on the prediction that the HLE predictor will perform the invalidation, set the address of the lock as a read set of the HLE transaction, inhibit any write to the lock by the lock-acquire instruction, and release the lock. Proceeding in an HLE transaction execution mode until an xrelease instruction is encountered or the HLE transaction encounters a transaction conflict;
Treating the HLE lock-acquire instruction as a non-HLE lock-acquire instruction based on predicting that the HLE predictor will not perform the invalidation and proceeding in a non-transaction mode;
Wherein the HLE estimator performs the invalidation or does not perform the invalidation in consideration of the success or failure of the prediction that the previous invalidation was not performed on the lock. A computer system that makes predictions . The method performed by the computer system comprises:
Updating the HLE predictor based on a successful prediction of the HLE transaction, the HLE predictor further comprising: predicting and updating whether the HLE transaction is likely to abort; The computer system according to claim 14. The method performed by the computer system comprises:
Monitoring non-transactional mode for attempts to access the lock by another process;
Incrementing a count of failed HLE transaction executions associated with the address of the lock upon detecting the access attempt by the another process;
The computer system according to claim 14, further comprising: The method performed by the computer system comprises:
Monitoring, in non-transactional mode, attempts by another process to access the memory area protected by the lock;
Incrementing a count of failed HLE transaction executions associated with the address of the lock upon detecting the access attempt by the another process;
17. The computer system according to any one of claims 14 to 16, further comprising: The method performed by the computer system comprises:
Initializing a count of successful HLE transaction executions associated with the address of the lock to zero based on the first encounter of an HLE transaction with the address of the lock;
Incrementing a count of failed HLE transaction executions associated with the lock address of the HLE transaction in the predictor based on aborting any subsequent HLE transaction having the address of the lock, A high count of failed HLE transaction executions indicating a high probability of an abort, said incrementing;
Incrementing the count of successful HLE transaction executions associated with the address of the lock of the HLE transaction in the HLE predictor based on completing any subsequent HLE transaction having the address of the lock;
18. The prediction of whether to perform the invalidation or not to perform the invalidation is performed in consideration of the count of the successful HLE transaction executions and the count of the failed HLE transaction executions. A computer system according to any one of the preceding claims. The method performed by the computer system comprises:
Tracking the count of the successful HLE transaction executions and the count of the failed HLE transaction executions within a time window;
Comparing the count of failed HLE transaction executions to a threshold number of failures during the time window;
Defaulting to a non-transactional mode for the remainder of the time window based on the count of failed HLE transaction executions exceeding the failed threshold number;
19. The computer system of claim 18, further comprising: The method performed by the computer system comprises:
20. The computer system of claim 19, further comprising resetting the count of successful HLE transaction executions and the count of failed HLE transaction executions to zero based on expiration of the time window.

Images