JP2016537709A - An adaptive process for data sharing using lock invalidation and lock selection - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a method, a computer program, and a computer system for adaptive sharing of data using lock invalidation and lock selection. In a Hardware Lock Elision (HLE) environment, a predictive decision is provided as to whether an HLE transaction actually acquires a lock and should be executed non-transactionally. Based on encountering the HLE lock-acquire instruction, based on the HLE predictor, determining whether to invalidate the lock and proceed as an HLE transaction, or to acquire the lock and proceed as a non-transaction; Based on the predictor's expectation to invalidate, set the address of the lock as the read set of the HLE transaction, prevent any writes to the lock by the lock-acquire instruction, and encounter an xrelease instruction that releases the lock Until the HLE transaction encounters transaction contention, the HLE lock-acquire instruction is LE lock-The acquire treated as command contains the allowed to proceed in non-transactional mode. [Selection] Figure 4

Description

  The present disclosure relates generally to transactional memory systems, and more particularly to a method, computer program, and computer for adaptive sharing of data using lock elision and locking selections -Regarding the system.

  In order to support increasing workload capacity demands, the number of central processing unit (CPU) cores on a chip and the number of CPU cores connected to shared memory continues to increase significantly. Increasing the number of CPUs that work together to handle the same workload is a significant burden on software scalability, for example, shared queues or data structures protected by traditional semaphores become hot spots, Produces a nearly linear n-way scaling curve. Traditionally, this is offset by the implementation of fine-grained locking in software and the low latency / high bandwidth interconnection in hardware. Implementing fine-grained locks to improve software extensibility can be very complex and error-prone, and at today's CPU frequencies, the latency of hardware interconnects is chip and system Limited by the physical dimensions of the light and the speed of light.

  An implementation of hardware transaction memory (HTM, or simply TM in this discussion) was introduced, where a group of instructions called transactions were seen by other central processing units (CPUs) and I / O subsystems. Sometimes 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 operation on the same memory location, the transaction execution is aborted and re-executed. May require trials. To date, 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. Patent No. 5,077,086, filed Aug. 28, 2002 and incorporated herein by reference, teaches a method and apparatus for distributed cache synchronization, named "Method and apparatus for the synchronization of distributed caches". . More particularly, this embodiment relates to a cache memory system, and more particularly suitable for use with a distributed cache, including use within a cache input / output (I / O) hub. It relates to the hierarchical cache protocol.

  Patent document 2 entitled “Partial cache line write transactions in a computing system with a write back cache” filed on Mar. 24, 1994 and incorporated herein by reference is a memory, input / output adapter and processor. The proposed computing system is taught. The processor includes a write-back cache that can store dirty data. In performing a consistent write from the input / output adapter to the memory, the data block is written from the input / output adapter to a memory location in the 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 whether 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 the data for that memory location is purged.

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

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

  A method, computer program, and computer system for adaptive sharing of data using lock invalidation and lock selection are provided.

  In a Hardware Lock Elision (HLE) environment, a method is provided for predictively determining whether an HLE transaction actually acquires a lock and should be executed non-transactionally. According to one embodiment of the present disclosure, the method is based on encountering an HLE lock-acquire instruction, based on the HLE predictor, invalidating the lock and proceeding as an HLE transaction or acquiring the lock. Based on determining whether to proceed as a non-transaction and the HLE predictor expects to invalidate, set the address of the lock as a read set for the HLE transaction and lock to the lock with the lock-acquire instruction. Proceed in HLE transaction execution mode and predict that the HLE predictor will not invalidate until it encounters an xrelease instruction that inhibits any write and releases the lock or until the HLE transaction encounters transaction contention. 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, a computer program product for predictively determining whether a HLE transaction actually acquires a lock and should be executed non-transactionally in a Hardware Lock Elision (HLE) environment is provided. be able to. The computer program product is readable by a processing circuit and based on encountering an HLE lock-acquire instruction, based on the HLE predictor, invalidates the lock and proceeds as an HLE transaction or obtains the lock Based on determining whether to proceed as a non-transaction and the HLE predictor expects to invalidate, set the address of the lock as a read set for the HLE transaction and lock to the lock with the lock-acquire instruction. Proceed in HLE transaction execution mode until the xrelease command that prevents any writing and releases the lock, or until the HLE transaction encounters transaction contention, and the HLE predictor performs invalidation. Storing instructions to be executed by the processing circuit to implement a method including treating the HLE lock-acquire instruction as a non-HLE lock-acquire instruction and proceeding in non-transaction mode based on Computer readable storage media.

  In another embodiment of the present disclosure, a computer system for predictively determining whether a HLE transaction actually acquires a lock and should be executed non-transactionally in a Hardware Lock Elision (HLE) environment is provided. . The computer system can include a memory and a processor in communication with the memory, and based on encountering the HLE lock-acquire instruction, invalidates the lock based on the HLE predictor, and as an HLE transaction. Based on deciding whether to proceed or acquire the lock and proceed as a non-transaction and predict that the HLE predictor will invalidate, set the address of the lock as the read set for the HLE transaction; inhibit all writes to the lock by the lock-acquire instruction and proceed in HLE transaction execution mode until an xrelease instruction is encountered that releases the lock or until an HLE transaction encounters transaction contention; Based on predicting that the E predictor will not invalidate, the HLE lock-acquire instruction is treated as a non-HLE lock-acquire instruction and proceeds in non-transaction mode. The

  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 clarity when it is easier for those skilled in the art to understand the present disclosure in conjunction with the detailed description.

2 illustrates an exemplary multi-core transactional memory environment according to embodiments of the present disclosure. 2 illustrates an exemplary multi-core transactional memory environment according to embodiments of the present disclosure. 2 illustrates exemplary components of an exemplary CPU according to embodiments of the disclosure. FIG. 4 shows a flow diagram of a method for adaptive sharing of data using a lock invalidation and selection between locks, according to an exemplary hardware or software embodiment. FIG. 4 shows a flow diagram in which a contention predictor, also called an HLE predictor or hardware lock virtualizer, is implemented in an environment where HLE support exists. FIG. 4 shows a flow diagram of a method for adaptive sharing of data using lock invalidation and selection between locks, according to an exemplary embodiment where there is no additional hardware capability. FIG. 4 shows a flow diagram of a method for adaptive sharing of data using lock invalidation and selection between locks, according to an illustrative embodiment with hardware lock monitoring. Fig. 4 illustrates an exemplary flow for adaptive sharing of data. Fig. 4 illustrates an exemplary flow for adaptive sharing of data. FIG. 8 is a schematic block diagram of hardware and software in a computer environment, according to at least one exemplary embodiment of the method of FIGS.

  Traditionally, computer systems or processors have only a single processor (also known as a processing unit or central processing unit). The processor included an instruction processing unit (IPU), a branch unit, a memory control unit, and the like. Such processors were able to execute a single program thread at a time. Time-share a processor by dispatching a program to run on a processor for a period of time and then dispatching another program to run on a processor for another period An operating system that can do this has been developed. As technology evolved, complex dynamic address translations including memory subsystem caches, as well as translation lookaside buffers (TLBs), were often added to the processor. The IPU itself was often called a processor. As technology continued to evolve, it became possible to package the entire processor as a single semiconductor chip or die, and these processors were called microprocessors. Later, processors incorporating multiple IPUs were developed, and these processors were often referred to as multiprocessors. Each such processor of a multiprocessor computer system (processor) can include an individual or shared cache, memory interface, system bus, address translation mechanism, and the like. A virtual machine and instruction set architecture (ISA) emulator adds multiple layers of software to a processor and uses multiple IP virtual processors by using a single IPU time slice within a single hardware processor. ”(Also known as a processor). As technology evolves further, multi-threaded processors have been developed, allowing single hardware processors with a single multi-threaded IPU to provide the ability to execute different program threads simultaneously, and thus a computer system Each thread of a multi-threaded processor became visible as a single processor. As technology has further developed, it has become possible to place 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, the terms processor, central processing unit, processing unit, microprocessor, core, processor core, processor thread, and thread are often used interchangeably. Aspects of the embodiments herein can be implemented by any or all processors, including those shown above, without departing from the teachings herein. Where the term “thread” or “processor thread” is used herein, it is believed that certain advantages of the embodiments could have been implemented in the processor thread implementation.

Transaction Execution in Intel®-Based Embodiments In Non-Patent Document 1, which is incorporated herein by reference in its entirety, Chapter 8 is partly achieved by multithreaded applications that achieve higher performance. Therefore, it is taught that an increase in the number of CPU cores can be utilized. However, writing multi-threaded applications requires the programmer to understand and take into account data sharing among multiple threads. Access to shared data generally requires a synchronization mechanism. Using these synchronization mechanisms, multiple threads update shared data, often using lock-protected critical sections to serialize operations applied to shared data Guarantee to do. Because serialization limits concurrency, programmers attempt to limit the overhead due to synchronization.

  Intel® Transaction Synchronization Extensions (Intel® TSX) dynamically determines if a processor needs to serialize a thread with a lock-protected critical section and if necessary Only allows this serialization to be done. This allows the processor to expose and exploit concurrency hidden in the application for dynamic unnecessary synchronization.

  In Intel (registered trademark) TSX, a code area (also referred to as “transaction area” or simply “transaction”) designated by a programmer is executed as a transaction. Once the transaction execution is successfully completed, all memory operations performed within the transaction area appear to occur instantaneously when viewed from other processors. A processor performs a memory operation on an executed transaction that is performed in a transaction area visible to other processors only when it is successfully committed, i.e., when the transaction completes execution successfully. Do. This process is often referred to as atomic commit.

  Intel® TSX provides two software interfaces for specifying code regions for transaction execution. Hardware Lock Elision (HLE) is a legacy compatible instruction set extension (including XACQUIRE and XRELEASE prefixes) for specifying transaction areas. 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 manner than is possible with HLE it can. HLE likes the backward compatibility of the traditional mutual exclusion programming model and wants to run HLE-compatible software on legacy hardware, but has a new lock invalidation feature 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® TSX also provides an XTEST instruction. This instruction allows the software to query whether the logical processor is executing a transaction in the transaction area identified by either HLE or RTM.

  Successful transaction execution guarantees atomic commit, so the processor executes the code region optimistically without explicit synchronization. If synchronization is not required for a particular execution, the execution can be committed without any cross-thread serialization. If the processor cannot commit atomically, optimistic execution fails. If optimistic execution fails, the processor rolls back execution and the process is called transaction abort. When a transaction aborts, the processor discards all updates performed in the memory area used by the transaction, restores the architectural state as if it had not been executed optimistically, and is non-transactional Resume execution at

  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 can prevent successful transaction execution. The memory address read from within the transaction area constitutes a read set for the transaction area, and the address written into the transaction area constitutes a write set for the transaction area. Intel® TSX maintains read and write sets with cache line granularity. Memory access contention occurs when another logical processor reads at some location in the transaction area's write set or writes at some location in the transaction area's read or write set. Access contention generally means that the code area needs to be serialized. Since Intel® TSX detects data contention at the cache line granularity, irrelevant data locations placed on the same cache line are detected as contention, resulting in a transaction abort. Transaction aborts can also occur due to transaction resource limitations. For example, this is a case where the amount of data accessed in the area exceeds the implementation-specific capability. In addition, some instructions and system events can cause transaction aborts. Frequent transaction aborts result in wasted cycles and increased inefficiencies.

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

  In HLE, programmers add the XACQUIRE prefix before instructions used to acquire locks that protect critical sections. The processor treats the prefix as a hint to elide the write associated with the lock acquisition operation. Even if the lock acquisition has a write operation associated with the lock, the processor does not add the address of the lock to the transaction area's write set 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 instruction with the XACQUIRE prefix, all other processors continue to consider the lock as available after the instruction. Since the logical processor executing the transaction does not add the address of the lock to the write set and does not perform an explicit write operation externally, other logical processors can read the lock without causing data contention. This allows other logical processors to enter the critical section protected by the lock and execute simultaneously. The processor automatically detects any data contention caused during transaction execution and performs transaction aborts as needed.

  Even though the invalidating processor does not perform any external write operations on the lock, the hardware guarantees the program order of the operations on the lock. 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. Lock release includes writing to the lock. If this instruction returns the value of the lock to the value that the lock had before the lock acquisition operation with the XACQUIRE prefix of the same lock, the processor ignores the external write request associated with releasing the lock. And do not add the address of the lock to the write set. Next, the processor attempts to commit the transaction execution.

  In HLE, even if multiple threads execute a critical section protected by the same lock, if no operations that cause any contention on each other's data are performed, the threads are not serialized at the same time. Can be executed. Even if the software uses a lock acquisition operation on a common lock, the hardware will recognize this, invalidate the lock, and execute the critical section in two threads without any communication through the lock (such as If communication was not required dynamically).

  If the processor is unable to transactionally execute the region, the processor executes the region non-transactionally and without invalidation. HLE-enabled software guarantees forward progression as well as the underlying non-HLE lock-based execution. For successful HLE execution, locks and critical section code must follow certain guidelines. These guidelines only affect performance, and no functional failure will occur if these guidelines are not followed. Hardware that does not have HLE support ignores the XACQUIRE and XRELEASE prefix hints, but these prefixes correspond to REPNE / REPE IA-32 prefixes that are ignored in instructions when XACQUIRE and XRELEASE are enabled. Therefore, no invalidation is performed. Importantly, HLE is compatible with existing lock-based programming models. Although improper use of hints does not cause functional bugs. Potential bugs already in the code can be exposed.

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

  The programmer uses the XBEGIN instruction to specify the beginning of the transaction code area and the XEND instruction to specify the end of the transaction code area. The XBEGIN instruction uses an operand that gives a relative offset to the fallback instruction address if the RTM region has not succeeded in executing the transaction.

  The processor may abort RTM transaction execution for a number of reasons. The hardware automatically detects the transaction abort condition and resumes execution from the fallback instruction address in the architectural state corresponding to the start of the XBEGIN instruction and the updated EAX register to explain the abort status. To do.

  The XABORT instruction allows the programmer to explicitly abort execution of the RTM region. The XABORT instruction uses 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. The hardware does not guarantee as to whether the RTM region has ever been successful in transaction commit, but most transactions that follow the recommended guidelines are expected to succeed in transaction commit. However, the programmer must always provide an alternative code sequence for the fallback path to ensure forward progression. This can be as simple as acquiring a lock and executing the specified code region non-transactionally. In addition, a transaction that is always aborted in a given implementation may be completed into a transaction in a future implementation. Thus, the programmer must ensure that the transaction path and the code path of the alternative code sequence are functionally tested.

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

Detection of RTM support The processor is CPUID. 07H. EBX. When RTM [bit11] = 1, RTM execution is supported. The application needs to check whether the processor supports RTM before using the RTM instruction (XBEGIN, XEND, XABORT). If these instructions are used on a processor that does not support RTM, a #UD exception will occur.

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

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 causes a #UD exception when used on a processor that does not support either HLE or RTM. I want.

HLE Lock Requirements In order for HLE execution to succeed in a transaction commit, the lock must meet certain characteristics and access to the lock must conform to the following specific guidelines.

  The XRELEASE prefixed instruction needs to restore the value of the invalidated lock to the value it had prior to acquiring the lock. This allows the hardware to safely invalidate the lock without adding it to the write set. The data size and data address of the lock release (with XRELEASE prefix) instruction must match that of the lock acquisition (with XACQUIRE prefix) instruction, and the lock crosses a cache line boundary I can't.

  The software should not write to an invalidated lock in the transaction HLE region with any instruction other than the XRELEASE prefix instruction, otherwise 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 results of invalidated locks acquired in the critical section. Such a read operation returns the value of the write to lock.

  The processor automatically detects violations of these guidelines and safely transitions to non-transactional execution without invalidation. Since Intel (R) TSX detects contention at the granularity of the cache line, writing to data placed on the same cache line as the invalidated lock causes other logical processors to invalidate the same lock. May be detected as a data race.

Transaction Nesting Both HLE and RTM support nested transaction regions. However, a transaction abort restores the state to the operation that initiated the transaction execution, 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 Programmers can nest the HLE region to an implementation-specified depth of MAX_HLE_NEST_COUNT. Each logical processor keeps track of the nested count internally, but this count is not available to software. HLE eligible instructions with a XACQUIRE prefix increment the nesting count, and HLE eligible instructions with an XRELEASE prefix decrement it. The logical processor enters transaction execution when the nesting count goes from zero to one. The logical processor attempts to commit only when the nesting 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, 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 that same lock. The processor can always track up to MAX_HLE_ELIDED_LOCKS number of locks. For example, if the implementation supports 2 MAX_HLE_ELIDED_LOCKS values and the programmer nests 3 HLE-identified critical sections (without executing an HLE-eligible instruction with an intervening XRELEASE prefix for any of the locks) By executing an HLE eligible instruction with an intervening XACQUIRE prefix for three individual locks, the first two locks are invalidated, but the third lock is not invalidated (but the transaction is written) Added to the set). However, execution still continues to the transaction. When 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 HLE execution when all invalidated XACQUIRE and XRELEASE pairs match, the nesting count is zero, and the lock meets the requirements. If execution cannot be committed atomically, execution transitions to non-transactional execution without invalidation, as if the first instruction did not have a XACQUIRE prefix.

RTM Nesting The programmer can nest the RTM region up to the implementation-specified MAX_RTM_NEST_COUNT. 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 attempts to commit only when the nesting count reaches 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 general transaction execution functions. The transaction processing behavior is implementation specific when the HLE and RTM are nested together, eg, the HLE is inside the RTM or the RTM is inside the HLE. However, in all cases, the implementation maintains HLE and RTM semantics. Some implementations may choose to ignore the HLE hint when used in the RTM region, and may cause a transaction abort when the RTM instruction is used in the HLE region. 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 is seamless.

Abort Status Definition The RTM communicates abort status to software using the EAX register. After RTM abort, the EAX register has the following definition:

  The EAX abort status for RTM provides only the cause of the abort. This in itself does not code whether an abort or commit occurred for the RTM region. The value of EAX may become 0 after RTM abort. For example, using a CPUID instruction inside an RTM area causes 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 executed atomically. Even if no memory operation is performed in the RTM region, XBEGIN is followed by XEND and the RTM region that has been successfully committed has the same ordering semantics as the LOCK prefix instruction.

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

Support for RTM-enabled debuggers By default, any debug exception within the RTM region will cause a transaction abort, restore the 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 7 of DR7 and bit 15 of IA32_DEBUGCTL_MSR are 1, execution will rollback due to any RTM abort due to a 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 be successfully executed and committed. However, Intel (R) TSX does not have such a guarantee. Transaction execution may be aborted for various reasons. In order to take full advantage of the transaction capabilities, programmers need to follow certain guidelines and increase the chances of a successful commit of transaction execution.

  This section discusses the various events that can cause a transaction abort. The architecture ensures that updates made within a transaction that later aborts execution will never be visible. Only committed transaction executions initiate an architectural state update. Transaction aborts never cause a functional failure and only affect performance.

Instruction-based considerations Programmers can safely use any instruction within a transaction (HLE or RTM) and can use a transaction at any privilege level. However, some instructions always abort transaction execution and execution is seamlessly and safely transitioned to a non-transaction path.

In Intel® TSX, most common instructions can be used inside a transaction without causing an abort. Typically, the following operations will 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 and YMM registers and the MXCSR register.

  However, programmers must be careful when mixing SSE and AVX operations within a transaction domain. A transaction may be aborted due to a mixture of an SSE instruction that accesses the XMM register and an AVX instruction that accesses the YMM register. Programmers can use string operations with REP / REPNE prefixes in transactions. However, long strings can cause aborts. Furthermore, the use of CLD and STD instructions can cause an abort if they change the value of the DF flag. However, if DF is 1, the STD instruction does not cause an abort. Similarly, if DF is 0, the CLD instruction does not cause an abort.

  Transactions are not usually aborted by instructions not listed here as causing an abort when used inside a transaction (for example, but not limited to, MFENCE, LFENCE, SFENCE, RDTSC, RDTSCP, etc.).

The following instructions abort transaction execution in any implementation:
・ XABORT
・ CPUID
・ PAUSE

Furthermore, in some implementations, the following instructions can 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 depends on the implementation.
• Operations on the architectural state of X87 and MMX ™ . This includes all MMX and X87 instructions, including FXRSTOR and FXSAVE instructions.
-Update of non-status part of EFLAG: CLI, STI, POPFD, POPFQ, CLTS.
Instructions to update segment registers, debug registers, and / or control registers: MOV to 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 transition: SYSTERTER, SYSCALL, SYSEXIT, and SYSRET.
TLB and cacheable controls: CLFLUSH, INVD, WBINVD, INVLPG, INVPCID, and memory instructions with non-transient hints (MOVNTDQA, MOVNTDQ, MOVNTI, MOVNTPD, MOVNTPS, and MOVNTPS).
Save processor state: XSAVE, XSAVEOPT, and XRSTOR.
-Interrupt: INTn, INTO.
IO: IN, INS, REP INS, OUT, OUTS, REP OUTS, and their modifications.
VMX: VMPTRLD, VMPTRST, VMCLEAR, VMREAD, VMWRITE, VMALL, VMLAUNCH, VMRESUME, VMXOFF, VMXON, INVEPT, and INVVPID.
SMX: GETSEC.
UD2, RSM, RDMSR, WRMSR, HLT, MONITOR, MWAIT, XSETBV, VZEROUPPER, MASKMOVQ, and V / MASKMOVDQU.

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

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

  Synchronization 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 did not occur. In HLE, the non-transaction code path is the same as the transaction code path, so if the instruction that caused the exception is re-executed into a non-transaction, these events will reappear and the associated synchronous event in non-transaction execution Properly delivered. If an asynchronous event (NMI, SMI, INTR, IPI, PMI, etc.) occurs during transaction execution, the transaction execution is aborted and may transition to non-transaction execution. Asynchronous events are pending and processed after the transaction abort is processed.

  Transactions only support memory-type operations that allow write-back caching. A transaction can always abort if the transaction involves any other type of memory. This includes instructions that fetch into the UC memory type.

  For memory access in the transaction area, the access (Accessed) flag and dirty (Dirty) flag of the page table entry referred to by the processor may have 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 to the outside, even if the transaction area is subsequently aborted. Some Intel® TSX implementations may choose to abort the transaction execution if these flags need to be updated. In addition, the processor's page table walk may be written to itself but provide access to an uncommitted state. Some Intel (R) TSX implementations may choose to abort the execution of a transaction area in this situation. Nevertheless, the architecture ensures that if a transaction region aborts, the state written in the transaction is not visible to the architecture due to the behavior of a structure like TLB.

  Transaction execution of self-modifying code can cause a transaction abort. Programmers should continue to follow the guidelines recommended by Intel® for writing self-correcting and cross-correcting code, even when using HLE and RTM. RTM and HLE implementations usually provide sufficient resources to execute a common transaction area, but restricting the implementation of the transaction area or making it larger than necessary will abort transaction execution and Transition to transaction execution may occur. The architecture does not guarantee the amount of resources available for transaction execution, nor does it guarantee that transaction execution will always succeed.

  If a competing request is made for a cache line that accesses the transaction area, it may hinder the successful execution of the transaction. For example, logical processor P0 reads line A in the transaction area, another logical processor P1 writes to line A (either inside or outside of the transaction area), and writing of logical processor P1 increases the transaction execution capability of 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), access to line A of P1 is the transaction execution capability of P0. If P0 is blocked, P0 may abort. In addition, other coherence traffic may appear as competing requests and cause an abort. Although these false conflicts may occur, it is considered uncommon. In the above scenario, the conflict resolution policy for determining whether P0 or P1 is aborted is implementation specific.

Typical transaction execution embodiments:
According to Non-Patent Document 2, which is hereby incorporated by reference in its entirety, there are basically three mechanisms necessary to implement atomic and isolated transaction domains: versioning and contention. There is detection and contention management.

  In order for a transaction code area to appear atomic, all modifications made by that transaction code area must be stored until commit time and separated 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 newly generated transaction values in place, and the previous memory values are stored separately in what is called an undo log. The lazy versioning system temporarily stores new values in what is called a write buffer and copies them to memory only at commit time. In both systems, a cache is used to optimize storage of the new version.

  Conflicts need to be detected and resolved to ensure that the transaction appears to be executed atomically. Two systems, eager and lazy versioning systems, detect conflicts by implementing either optimistic or pessimistic conflict detection policies. An optimistic system runs transactions in parallel and checks for conflicts only at transaction commit time. The pessimistic system checks for contention for each load and store. Similar to versioning, contention detection also uses a cache to mark 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 many contention management policies, some more suitable for optimistic conflict detection and some more suitable for pessimistic conflict detection. Some exemplary policies are described below.

  Each transaction memory (TM) system requires both versioning detection and conflict detection, so these options are available in four separate TM designs: Eager-Pesmicistic (EP), Eager-Optimistic ( It produces 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-enabled CPUs (CPU1 114a, CPU2 114b, etc.) on one die 100 connected to the 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 the memory to be executed, and data (operands) at memory locations operated by the CPUs 114a, 114b. Can have a split cache consisting of data caches 118a, 118b that support TM. In one implementation, multiple die 100 caches are interconnected to support cache coherency between multiple die 100 caches. In one implementation, a single cache is used rather than a split cache, holding both instructions and data. In one implementation, the CPU cache is 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 the die 100. In another implementation, each die 100 may have access to a shared cache 124 that is shared among all processors of all dies 100.

  FIG. 2 shows details of an exemplary transaction CPU 114, including additions to support TM. Transaction CPU 114 (processor) may include hardware to support register checkpoint 126 and special TM register 128. The transaction CPU cache may include the MESI bit 130, tag 140, and data 142 of a conventional cache, but similarly, for example, an R bit 132 indicating that a line has been read by the CPU 114 during transaction execution, and a transaction And a W bit 138 indicating that the line was written by the CPU 114 during execution.

  In any TM system, an important detail for the programmer 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-transaction store and the transaction that read the address must also 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 referred to as strong atomicity). Thus, a non-transactional load cannot see uncommitted data, and a non-transaction store causes an atomicity violation in any transaction that reads that address. Systems where this is not the case are said to implement weak isolation, sometimes called weak atomicity.

  Strong separation is often more desirable than weak separation because the conceptualization and implementation of strong separation is relatively easy. In addition, if a programmer forgets to enclose some shared memory reference in a transaction, a bug will arise and with strong isolation, the programmer will see a non-transactional area that causes an atomicity violation, so the programmer will have a single debug interface Is often used to detect oversight. In addition, a program written in one model may operate differently on another model.

Furthermore, 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 needs to be modified to include a read barrier and a write barrier, which improves performance. There is a possibility of damage. Although a great deal of effort has been expended to remove many unnecessary barriers, these techniques are often complex and performance is usually much lower than that of HTM.

  Table 2 shows the basic design space for transactional memory (versioning and contention detection).

Eager-Pessimistic (EP)
This first TM design, described below, is known as eager-pessimism. The EP system stores its write set “in place” (hence the name “eager”), and “undo log” stores the old value of the overwritten line to support rollback. To store. The processor uses the W cache bit 138 and the R cache bit 132 to keep track of read and write sets and detect contention when a snooped load request is received. 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. The EP system also requires undo log initialization, the details of which depend on the log format, but in many cases it initializes a log base pointer to a pre-allocated area of thread private memory. And clearing the log boundary register.

  Versioning: In EP, the code of state transitions (Modified, Exclusive, Shared, and Invalid) of MESI 130 due to the way that eager versioning is designed to work 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, standard coherence transitions are applied (S (Shared) → S, I (Invalid) → S, or I → E (Exclusive)), issuing load misses as needed. , R bit 132 is also set. Similarly, standard transitions are applied to line writing (S → M, E → I, I → M), and a miss is issued if necessary, but in addition, the W (Write) bit 138 is also set. To do. If the current transaction aborts, when the line is written for the first time, the old version of the entire line is loaded and then written to the undo log and saved. The newly written data is then stored “in place” over the old data.

  Conflict detection: Pessimistic conflict detection looks for conflicts between transactions using coherence messages exchanged during a miss or upgrade. When a read miss occurs within a transaction, other processors receive a load request, but ignore them if they do not have the required line. If other processors have the required line non-speculatively or have line R132 (Read), then downgrade this line to S, in some cases they are in MESI M or E state If it has a line, issue a cache-to-cash transfer. 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 a 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: Since conflict detection is performed on every load, a transaction always has exclusive access to each write set. Thus, 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 is correct from its log You have to wait to restore the version. Such 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 no-op. Pessimistic conflict detection detects conflicts early, thereby reducing the number of “doomed” transactions. For example, if two transactions are involved in a Write-After-Read dependency, that dependency is detected instantaneously in pessimistic conflict detection. However, in optimistic conflict detection, such conflicts are not detected until the writer commits.

  Eager-pessimistic also has the following characteristics: As described above, when first written to the cache line, the old value must be written to the log, resulting in extra cache access. Abort is expensive because it requires log undo. 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 specific serializable schedules.

  In addition, since conflicts are handled as they occur, there is a possibility of livelock and careful contention management mechanisms must be utilized 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 time (still R and Use the W bit).

  Versioning: Similar to the EP system, the LO-designed MESI protocol is implemented outside the transaction. Once inside the transaction, reading the line will result in a standard MESI transition, but setting the R bit 132 as well. Similarly, writing a line sets the W bit 138 of the line, but the processing of MESI transitions in the LO design is different from that in the EP design. First, in lazy versioning, new versions of written data are stored in the cache hierarchy until commit, but 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, because of the optimistic conflict detection feature, upgrade mistakes are not required: conflict detection is done at commit time, so if a transaction has a line in the S state, the transaction simply writes to the line and changes are otherwise It is only necessary to upgrade the line to the M state without communicating with any transaction.

  Conflict detection and validation: In order to validate transactions and detect conflicts, the LO communicates speculatively modified line addresses to other transactions only when it is preparing to commit. In validation, the processor sends a single, possibly large, network packet that includes all addresses in the write set. Data is not sent but is left in the committer's cache and marked as dirty (M). To keep track of these speculatively modified lines to build this packet without searching the cache for lines marked W, a “store” has 1 bit per cache line. Use a simple bit vector called a buffer. Other transactions use this address packet to detect a conflict: if the address is found in the cache and the R bit 132 and / or W bit 138 is set, a conflict is initiated. If a line is found but neither R132 nor W138 is set, the line is simply invalidated, which is similar to the exclusive load process.

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

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

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

  Lazy-optimistic has the following features: Abort is very fast, does not require additional loading or store, and only makes local changes. There can be more serializable schedules than found in the EP, which allows the LO system to more actively infer that the transaction is independent, which is more High performance can be achieved. Ultimately, slow competition detection can increase the likelihood of forward progression.

  Lazy-optimistic also has the following characteristics: validation requires a global communication time proportional to the size of the write set. Since conflicts are only detected at commit time, failed transactions can be wasted work.

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

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

  Contention detection: LP contention detection works in the same way as that of EP: Look for contention between transactions using coherence messages.

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

  Commit: As in LO, commit does not require any 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: just use the store buffer to invalidate the write set, clear the W bit 138 and R bit 132, and the store buffer.

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

Eager-Optimistic (EO)
The final combination of versioning and competition detection is eager-optimistic (EO). EO can be a sub-optimal option for HTM systems: new transaction versions are written in-place, so conflicts must be noticed when a conflict occurs (ie, when a cache miss occurs) . However, since EO waits for conflict detection until commit time, these transactions become “zombies”, continue execution, waste resources and are “destined” to 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 for 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. In addition, since conflict checking is also expensive in STM, optimistic conflict detection offers the advantage of performing this operation collectively.

Contention management Once the system has decided to abort the transaction, it was described above how the transaction rolls back, but since two transactions are involved in contention, which transaction should be aborted and which abort Topics that should be started and when an aborted transaction should be retried should be considered. These are topics addressed by contention management (CM), an important component of transactional memory. Various established methods for managing how the system initiates an abort and which transactions should be aborted in contention are described below.

Contention Management Policy A contention management (CM) policy is a mechanism that determines which transactions involved in a conflict should be aborted and when the aborted transaction should be retried. For example, retrying an aborted transaction instantly often does not lead to the best performance. Conversely, it uses a backoff mechanism that delays retrying aborted transactions, but may provide better performance. STM is initially committed to finding the best contention management policy, and many of the policies outlined below were originally developed for STM.

  The CM policy utilizes a number of measures for making decisions, including transaction age, read and write set sizes, previous abort counts, and so forth. There are an infinite number of scale combinations for making such a determination, but specific combinations will be described below in order of increasing complexity.

  To establish some terminology, first note that there are both attackers and defenders in the competition. 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. In either case, the defender is a transaction that receives an attacker's request.

  Aggressive CM policies retry either attackers or defenders instantly and always. In LO, aggressive means that the attacker always wins, and therefore aggressive is sometimes called the committer's victory. These policies were used for the earliest LO systems. In the case of an EP, a positive can be either a defender win or an attacker win.

  The resumption of a competing transaction that immediately faces another contention always causes a waste of work, ie the interconnected bandwidth refills the cache miss. A polite CM policy uses an exponential backoff (but can also use linear) before resuming contention. In order to prevent starvation, ie the situation where the process does not have resources allocated by the scheduler, exponential backoff significantly increases the success of the transaction after approximately n retries. To increase.

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

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

  Since aborts waste work, it makes sense to stall an attacker until the defender finishes its transaction, resulting in better performance. Unfortunately, such a simple scheme can 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. Is. The second rule is that if T1 has a higher priority than T0 and is not waiting, T0 waits until T1 commits, aborts, or starts waiting (in this case, the first Rules apply). Greedy provides some guarantee about the deadline for executing a set of transactions. One EP design (Log ™) achieves a stall due to conservative deadlock avoidance using CM policies similar to Greedy.

The example MESI coherency rule provides four possible states where a cache line of a multiprocessor cache system may exist, ie, four possible states M, E, S, I defined as follows: To do. :
Modified (M): The cache line exists only in the current cache and is dirty. That is, the cache line is corrected from the value in the main memory. The cache must write back data to main memory at some point in the future before allowing any other reading of the main memory state (which is no longer valid). The line changes to the exclusive state by 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 a Shared state at any time in response to a read request. Alternatively, the cache line can change to the Modified state when it is written.
Shared (S): This cache line can be stored in other caches on the machine, indicating that it is “clean”. That is, this cache line coincides with the main memory. The line can be discarded (changed to the Invalid state) at any time.
Invalid (I): Indicates that this cache line is invalid (not used).

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

  In another aspect of TM design, the system is designed with a transaction store buffer. Patent Document 3 and at least Patent No. 3 entitled “Methods and Apparatus for Reordering and Renaming Memory References in a Multiprocessor Computer System” filed on March 31, 2000, which is incorporated herein by reference in its entirety. A method for reordering and renaming memory references in a multiprocessor computer system having a second processor is taught. 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 obtains exclusively a cache line containing data by a first private cache for each of a plurality of gated store requests for storing data received by a first processor. And storing data in the first buffer. When the first buffer receives a load request to load specific data from the first processor, the specific 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 load request for the predetermined data from the second cache, an error condition is indicated, and if the load request for the predetermined data corresponds to 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 these transactional memory functions is the transaction backup register file to hold the contents of the pre-transaction GR (general purpose registers), the 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 transactional memory, and is described in part in Non-Patent Document 3, which is incorporated herein by reference in its entirety. .

Table 3 shows an exemplary transaction. Because an abort condition may be encountered in every execution attempt, for example due to repeated contention with other CPUs, it is not guaranteed that a transaction initiated with TBEGIN will always complete successfully with 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 reliable 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 and are likely to touch a few discrete memory locations and use only simple instructions. For these transactions, IBM zEnterprise EC12 introduces the concept of constrained transactions. Under normal conditions, the CPU 114 ensures that the constrained transaction eventually ends successfully even without giving a strict limit on the number of retries required. A constrained transaction begins with a TBEGIN instruction and ends with a normal TEND. Implementing tasks as a constrained or unconstrained transaction generally provides very comparable functionality, but constrained transactions simplify software development by removing the need for a fallback path. The IBM transaction execution architecture is further described in [4], which is incorporated herein by reference in its entirety.

  A constrained transaction begins with a TBEGIN instruction. Transactions initiated with TBEGIN must follow a list of programming constraints. Otherwise, the program uses a non-filterable constraint-violation interruption. Illustrative constraints include, but are not limited to, a transaction can execute up to 32 instructions, all instruction text must be in a contiguous 256-byte range of memory, a transaction Contains only relative branches that point forward (ie, there are no loops or subroutine calls), and the transaction can access up to four aligned octwords of memory (octwords are 32 bytes). And instruction set restrictions to exclude complex instructions such as decimal or floating point arithmetic. Many commons such as doubly linked list-insert / delete operations, including a very powerful concept of atomic compare-and-swap that targets up to four aligned ocwords A constraint is selected so that the operation can be performed. At the same time, the constraints are chosen conservatively so that future CPU implementations can guarantee transaction success without the need for adjustments to the constraints, because this would otherwise lead to software incompatibility. is there.

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

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

Since interrupt filtering is implicitly turned off, all exceptions in a constrained transaction result in an interrupt to the operating system (OS). The success of final transaction termination depends on the OS's ability to page in at most 4 pages touched by any constrained transaction. The OS must also guarantee a time slice that is 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, no lock test is shown, but this can be added when constrained transactions and lock-based code are mixed.

  In the event of repeated failures, software emulation is performed using millicode as part of the system firmware. Advantageously, constrained transactions have the desired characteristics because 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, simple instructions are dispatched as a single micro-op (micro operation), and more complex instructions are divided into multiple micro-ops 232b. Micro-ops (Uops 232b shown in FIG. 3) are written to the consolidated issue queue 216, from which they can be issued 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. The global completion table (GCT) 232 holds any micro-op and transaction nesting depth (TND) 232a. The GCT 232 is written in order upon decoding and tracks the execution status of each micro-op and completes the instruction when all the micro-ops 232b of the oldest instruction group have been executed successfully.

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

  Coherency is managed by a modification of the MESI protocol. The cache lines can be owned 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 the upper level cache to the lower level cache and between the L4s. If one core misses L1 240 (Figure 3) and L2 268 (Figure 3) and requests a cache line from local L3, L3 checks whether L3 owns this line and if necessary In order to guarantee coherency, XI is sent to L2 268 (FIG. 3) / L1 240 (FIG. 3) currently owned under L3, and then the cache line is returned to the requester. If the request also misses L3, L3 sends the request to L4, and L4 enforces coherency by sending XI to all required L3s under that L4 and to neighboring L4s. L4 then responds to the requesting L3, which forwards the response to L2 268 (FIG. 3) / L1 240 (FIG. 3).

  Cache line cross-query from lower level cache due to eviction to higher level cache caused by associative overflow from request to other cache lines due to cache hierarchy inclusion rules Note that (XI) is done. These XIs can 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 transfers 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 "accept" the XI, or send a "reject" response if the dirty data needs to be evicted first before accepting the XI. L1 cache 240 (FIG. 3) / L2 cache 268 (FIG. 3) is store-through, but has a store in the store queue that needs to be sent to L3 before downgrading the exclusive state. Can reject remote-XI and exclusive-XI. The rejected XI is repeated by the sender. A Read-only-XI is sent to the cache that owns the line read-only and no response is required for such XI because such XI cannot be rejected. 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. The instruction decode unit (IDU) 208 constantly monitors the current transaction nesting depth (TND) 212. When the IDU 208 receives the TBEGIN instruction, the nesting depth is incremented, and conversely, it is decremented at the time of the TEND instruction. For every dispatched instruction, the nesting depth is written to GCT 232. 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. Transaction state is also written into issue queue 216 for consumption by the execution unit, mostly by load / store unit (LSU) 280. The TBEGIN instruction can 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, if the AR / FPR modification instruction is decoded and the modification mask blocks it, the IDU 208 can place an abort request in the GCT 232. When the instruction becomes next-to-complete, completion is blocked and the transaction aborts. If it is 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 unit (FXU) 220, and in the case of a transaction abort A pair of GRs 228 is saved in a special transaction backup register file 224 that is used to later restore the contents of GR228. TBEGIN also generates a micro-op 232b to perform a TDB accessibility test if 1 is specified, and this address is stored in a dedicated register for later use in the event of an abort. The In decoding the outermost TBEGIN, the instruction address and instruction text of the TBEGIN are also stored in a dedicated register for potential later abort processing.

  TEND and NTSTG are simple micro-op 232b instructions. NTSTG (non-transactional store) is marked as non-transactional in the issue queue and is treated like a normal store, except that the LSU 280 can handle it properly . TEND is a no operation at the time of execution, and when the TEND is completed, the transaction is terminated.

  As mentioned above, instructions that are in a transaction are marked as such in issue queue 216, but are executed almost unchanged otherwise, and LSU 280 is described in the next section as follows: Perform an isolation track.

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

  During execution, Program Event Record (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 cause a random abort when enabled by transaction diagnostic control.

Transaction Isolation Tracking The load / store unit tracks the cache line accessed during transaction execution and triggers an abort if an XI (or LRU-XI) from another CPU conflicts with the footprint. If the competing XI is exclusive or remote XI, the LSU rejects the XI and returns to L3 in the hope that the transaction will be terminated before the L3 repeats the XI. This “stiff-arming” is very useful in high contention transactions. To prevent a hang-up when the two CPUs push each other, an XI rejection counter is implemented that triggers a transaction abort when the threshold is met.

  The L1 cache directory 240 is conventionally implemented with a static random access memory (SRAM). In a transactional memory implementation, the directory valid bits 244 (64 rows × 6 ways) are moved to normal logic latches, and two more bits for each cache line: TX-read bit 248 and TX-dirty bit 252. To be replenished.

  When a new outermost TBEGIN (interlocked to the previous still pending transaction) is decoded, the TX-read 248 bit is reset. The TX-read 248 bit is set at runtime by all load instructions marked as “transactional” in the issue queue. Note that this can result in excessive markup when speculative loads are performed, for example, on mispredicted branch paths. An alternative to setting the TX-read bit when the load is complete is too expensive for the silicon area because multiple loads can be completed simultaneously, requiring a large number of read ports on the load queue. there were.

  The store is performed in the same way as in non-transactional mode, but the transaction mark is placed in the store queue (STQ) 260 entry of the store instruction. At the time of write back, when data from STQ 260 is written into L1 240, the TX-Dirty 252 bit in L1 directory 256 is set for the written cache line. Store / writeback to L1 240 occurs only after the store instruction completes, and at most one store is written back per cycle. Prior to completion and write back, the load can access the data from STQ 260 by store transfer, and after write back, CPU 114 (FIG. 2) can store 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 the TX-mark of the store that has not been written is also cleared in STQ 260, and a valid pending store is changed to a normal store. Change to

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

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

  When L1 240 receives an XI, L1 240 accesses the directory to check the validity of the address in L1 240 that has been queried (XI), and the TX-read bit on the queried line (XI) If 248 is active and XI is not rejected, LSU 280 triggers an abort. When a cache line with an active TX-read bit 248 is made least recently used (LRU) from L1 240, a special LRU extension vector is TX-read on that line for each of the 64 rows of L1 240. Recall that there was a line. Since there is no exact address tracking for LRU extensions, any unrejected XI hits a valid extension line and LSU 280 triggers an abort. Provided that the conflict with other CPUs 114 (FIG. 2) for inaccurate LRU extension tracking does not cause an abort, the provision of an LRU extension effectively improves read footprint capability and associativity from L1 size to L2 size.

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

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

  For transactional memory performance, the L2 cache 268 returns a little more clean line (7 cycle L1 miss penalty), so invalidate any TX-dirty cache line from L1 240 on transaction abort Is acceptable. However, in terms of performance (and silicon area for tracking), let L2 268 be written to the transaction store before the transaction ends, and then all dirty L2 on abort (or worse, with shared L3) Invalidating the cache line is not acceptable.

  Both the store bandwidth and transaction memory store processing issues can be addressed with the collect store cache 264. The cache 264 is a 64 entry circular queue, and each entry holds 128 bytes of data with valid bits of byte-precise. In a non-transactional operation, upon receiving a store from LSU 280, store cache 264 checks whether an entry with the same address exists and if so, collects the new store into the existing entry. If there are no entries, 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 a new outermost transaction starts, all existing entries in store cache 264 are marked closed so that no new store can be collected there, and eviction of these entries for L2 268 and L3 begins Is done. From that point on, the transaction store obtained from the LSU280 STQ 260 allocates new entries or gathers in existing transaction entries. The write back of these stores to L2 268 and L3 is blocked until the transaction is successfully completed, at which point the later (post-transaction) store is closed until the next transaction closes their entries again. Can continue to be collected in existing entries.

  The store cache 264 is queried for every exclusive XI or remote XI, causing a XI rejection 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 a hangup.

  When the store cache overflows, the LSU 280 requests a transaction abort. When LSU 280 attempts to send a new store that cannot be merged into an existing entry, LSU 280 detects this condition 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 evicted transactionally from L1 240, but these 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.

  When a transaction aborts, it is notified to the store cache and all entries holding transaction data are invalidated. The store cache also has a mark every 1 doubleword (8 bytes) as to whether an entry has been written with the NTSTG instruction-these doublewords remain valid across transaction aborts.

Functions 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 that are fetched and executed from memory as well as application program and operating system (OS) instructions. The firmware resides in a restricted area of main memory that is not accessible to customer programs. When the hardware detects a situation where the millicode needs to be called, the instruction fetch unit 204 switches to “millicode mode” and begins 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 transactional memory, millicode is involved in a variety of complex situations. Every transaction abort calls a dedicated millicode subroutine to perform the necessary abort operation. Transaction abort millicode starts by reading a special purpose register (SPR) that holds the abort cause, potential exception cause, and 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 save mask that is needed to know which GR228 the millicode will restore.

  The CPU 114 (FIG. 2) supports special millicode dedicated 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 complete, 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 an abort is caused by an unfiltered program interrupt.

  The TABORT instruction can be implemented in millicode, that is, when the IDU 208 decodes TABORT, the TABORT instruction instructs the instruction fetch unit to branch to the TABORT millicode from which the millicode is aborted in common. • Branches to a subroutine.

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

  For constrained transactions, millicode can constantly monitor the number of aborts. The counter is reset to 0 when TEND completes successfully or if an interrupt to the OS occurs (it is not known if the OS will return to the program or when the OS will return to the program). . Depending on the current abort count, the millicode can call certain mechanisms to increase the likelihood that a subsequent transaction retry will be successful. This mechanism can be caused by speculative access to data that is not actually used by the transaction, for example, continuously increasing the random delay between retries and reducing the amount of speculative execution. Avoiding encountering an abort. As a last resort, before releasing the other CPU and proceeding with normal processing, broadcast the millicode to the other CPU to stop all competing work and retry the local transaction. it can. Since multiple CPUs need to be coordinated so as not to cause a deadlock, some serialization between millicode instances on different CPUs is required.

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

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

HLE, as mentioned above, allows programs written to use conventional lock code to take advantage of the hardware that implements transaction execution. However, in a high contention memory region, if a contention occurs, the processor can abort the transaction and execute the critical section again using pessimistic locking behavior. In one embodiment, any lock that crosses the cache line cannot be invalidated and automatically triggers a re-execution without HLE. Thus, if it is known that a critical section always fails as a transaction, defaulting to transaction execution and then successfully resuming with a lock may degrade performance.

  At 410, when the processor, i.e., CPU 114 (Fig. 2) initiates a code sequence to access the memory region, CPU 114 (Fig. 2) may have a contention predictor (i.e., either hardware or software). , HLE predictor or hardware lock virtualizer) to try to predict whether lock invalidation is likely to succeed or whether a lock should be used instead. In operation, the contention predictor can operate in various hardware and software environments, as described below. However, if the contention predictor refers to an embodiment of contention prediction within the HLE environment, the contention predictor can also be referred to as an HLE predictor. In one embodiment, a simple count of successful transaction executions can be kept, for example, in a hardware register or memory location for each thread, or can be shared for all threads. When the threshold representing the count of successful transaction executions is exceeded, at 410, the contention predictor determines that the transaction execution path, ie, lock invalidation, is less than the non-transaction execution path, ie, lock, at 455. It can be predicted that it may be effective. In at least one embodiment, the counter is initially initialized to prefer a 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 transaction execution relative to lock acquisition and execution can be calculated in hardware or by instructions inserted into the program stream. Based on the calculated relative costs, the contention predictor predicts that the transaction path or non-transaction path is more effective, for example because the predicted path is less expensive to run or less likely to encounter interference. can do. In another embodiment, the compiler can implicitly insert behavior hints into the contention predictor and select either a transaction execution path at 420 or a lock path at 455 at 410. The CPU 114 (FIG. 2) can begin executing the critical section as a transaction at 420 and update the data as needed at 425. At the end of the transaction at 430, but before committing the result, the CPU 114 (FIG. 2), at 435, interferes with the transaction aborting (ie, two or more code sequences in parallel on the same data). It can be determined whether (operation) 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 the CPU 114 (FIG. 2) detects interference at 435, execution is resumed at 455 using a lock. At 460, the critical section must explicitly acquire a lock that protects the memory area being accessed. However, the lock requester may be made to wait in an action called spinning until the lock is released by a competing process. Eventually, when the lock is acquired at 460, the critical section can continue processing. Once the data protected by the lock is updated at 470, 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 exists. As mentioned above, HLE is Intel's traditional compatible instruction set extensions, including XACQUIRE and XRELEASE, which allow programs written to use traditional lock code to effectively Allows the opportunity to use hardware that implements transaction execution without the need to modify it. In this embodiment, the HLE predictor is a specific example of Intel® HLE.

  At 505, the CPU 114 (FIG. 2) executes an Intel® XACQUIRE prefix instruction to begin the HLE sequence with the associated lock acquisition transaction. In one embodiment, the sequence can be expressed 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, a contention predictor, or HLE predictor, is invoked. Based on the prediction, lock invalidation can be performed or a lock can be acquired. With a prediction between lock invalidation and lock acquisition, the process can continue in substantially the same manner as described at 420-475 in FIG.

  Referring to FIG. 6, reference numeral 600 is generally for adaptive sharing of data using a choice between lock invalidation and lock, according to an exemplary embodiment where there is no additional hardware facility. A flow diagram of the method is shown. In this exemplary embodiment, hints to the contention predictor can be provided in the code stream of the application program, for example, through the operating system or by hardware. For example, in one embodiment, the programmer may explicitly insert one or more instructions, or the compiler may implicitly insert behavior hints into the contention predictor. The contention predictor can maintain a history vector or count to track the number of both successful predictions and unsuccessful predictions, ie, mispredictions, over a period of time, eg, 1 second. Next, at 610, the contention predictor can compare the mispredict count with the threshold number of failures in the time window. When the misprediction exceeds the threshold number of failures during the time window, the contention predictor can default to execution with lock, 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 simultaneously updating data for which multiple transactions compete. By temporarily selecting a lock as the default, the contention predictor avoids the possibility of having to restart a failed transaction and can improve throughput by avoiding transaction aborts. However, once the time window expires, the contention of the memory area may have relaxed and the contention predictor can attempt to execute the transaction again. In one embodiment, the contention predictor is implemented in software, and the determination of whether to perform lock invalidation or lock is determined by a first version of code in which the software implemented algorithm implements lock invalidation. Or by passing control to a second version of code that implements lock acquisition. In other embodiments, the decision 610 reflects the expected interference or non-interference associated with the field that is the target of the update transaction in response to an instruction to update a particular entry by software based on the history of interference. And implemented using alternative tests.

  At 655, the critical section must explicitly acquire a lock that protects the memory area being accessed. However, the lock requester may be forced to wait until a lock is released by a competing process in an action called spin. Once the lock is finally acquired 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, the CPU 114 (FIG. 2) can check for the 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 failed and successful transaction execution counts, reset the time window effectively, and start the contention predictor retraining. Can do.

  If the misprediction does not exceed the threshold number of failures during the time window, then at 610, the contention predictor combines lock invalidation, ie, an HLE transaction, or an explicit read of the lock word rather than a lock acquisition. Transactions that implement lock invalidation can be selected. When selected to run 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 a lock word in the read set) At 615, the CPU 114 (FIG. 2) can increment the count of successful transaction executions. The HLE transaction at 620 can update the data as needed at 625. After the end of the transaction at 630, but before committing the result at 635, CPU 114 (FIG. 2) causes interference (ie, two or more code sequences to operate on the same data in parallel) resulting in an abort of the transaction. It can be determined whether or not) 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 interference at 635, the failed transaction is counted as a misprediction and is used to train the contention predictor to make the contention predictor's future predictions more accurate. Therefore, at 650, the failed transaction execution count is incremented. At 655 and 660, the CPU 114 (FIG. 2) can now acquire a lock on the memory region and attempt to resume the critical section non-transactionally, i.e., using the lock. When the data protected by the lock is finally updated at 670, the critical section processing is complete and the lock can be released at 675. At 680, the CPU 114 (FIG. 2) can check for the expiration of the time window. If the time window has not expired, then processing ends at 680. However, if the time window has expired, then at 685, the failed and successful transaction execution counts can be reset, effectively initiating retraining of the contention predictor.

  Referring now to FIG. 7, reference numeral 700 generally illustrates an exemplary embodiment in which a method for adaptive sharing of data can include a monitoring facility in hardware when a lock is implemented. A flow diagram is shown. In FIG. 7, the processing of HLE transactions, ie 710 to 750, is substantially similar to the way the embodiment of FIG. 6 processes HLE, ie 610 to 650. However, FIG. 7 introduces a hardware lock monitoring facility for the path through which critical sections are executed non-transactionally. In this embodiment, the hardware lock monitoring facility will return the result as if the critical section was actually executed as an HLE transaction while the critical section allowed execution within the locked memory region. Try to minimize mispredictions by making predictions. Upon successful acquisition of the lock at 760 and 765, at 770, the hardware lock monitoring facility can begin monitoring the status of the lock. At 775, the critical section updates the data in the locked memory region and ends execution at 780 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 this critical section was executed as a transaction rather than non-transactionally Accesses attempted by other processes have resulted in interference and transaction failures. In one embodiment, only locks are monitored. In another embodiment, data updated as part of the locked area is monitored. 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 can monitor all data access attempts within a locked memory region. If another process attempts to access data in this area, then at 790, the hardware lock monitoring facility can count this as interference and potential transaction failure. Thus, the contention predictor can learn to predict more accurately whether transactional or non-transactional execution is likely to succeed.

  In another embodiment, at 750, when the transaction execution failure count is incremented, a restart flag may be set. Next, at 755, when the count of successful transaction executions is incremented, the resume flag can be reset. 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 resume with a lock at 755, The prediction accuracy can be improved.

  Referring now to FIG. 8, in one embodiment, in a Hardware Lock Elision (HLE) environment, predictively determining 810 whether an HLE transaction should actually acquire a lock and execute non-transactionally. Based on encountering the HLE lock-acquire instruction, based on the HLE predictor, determining 820 whether to invalidate the lock and proceed as an HLE transaction, or acquire the lock and proceed as a non-transaction 820; Xr which sets the address of the lock as a read set of the HLE transaction, inhibits any write to the lock by the lock-acquire instruction, and releases the lock based on predicting that the HLE predictor will invalidate The HLE lock-acquire instruction is based on proceeding 830 in HLE transaction execution mode until the lease instruction is encountered or until the HLE transaction encounters transaction contention, and the HLE predictor expects no invalidation. 840 as a non-HLE lock-acquire instruction and proceeding in non-transaction mode.

  Referring now to FIG. 9, in one embodiment, updating the HLE predictor is based on a successful HLE prediction 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 and any subsequent HLE transaction with the lock address is completed The HLE predictor increments the count of failed HLE transaction executions associated with the HLE transaction lock address, where a high count indicates a high probability of abort 920. In non-transaction mode, monitor an attempt to access the lock by another process and increment 950 the failed HLE transaction count when an access attempt by another process is detected. Tracks the count of successful and failed HLE transaction executions within the time window and is in non-transactional mode for the remainder of the time window based on the failed HLE transaction execution count exceeding a threshold number of failures. The default setting is 970. Based on the expiration of the time window, the successful HLE transaction execution count and the unsuccessful HLE transaction execution count are reset 960 to zero.

  With reference now to FIG. 10, the computing device 1000 may 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, one or more computer readable RAMs 822, and one or more computer readable ROMs on one or more buses 826; An 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. One or more operating systems are each for execution by one or more of each processor 820 via one or more of respective RAMs 822 (typically 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 is a semiconductor storage device such as ROM 824, EPROM, 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 is also one or more computers such as a thin provisioning storage device, CD-ROM, DVD, SSD, memory stick, magnetic tape, magnetic disk, optical disk, or semiconductor storage device. Also included is an R / W drive or interface 832 for reading from and writing to readable tangible storage device 936. The R / W drive or interface 832 is used to load device driver 840 firmware, software, or microcode into the tangible storage device 936 to facilitate communication with the components of the 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. The operating system 828 associated with the computing device 1000 communicates with an external computer (eg, a server) via a network (eg, the Internet, a local area network, or a wide area network) and a respective network adapter or interface 836. To the computing device 1000. From the network adapter (or switch port adapter) or interface 836, the operating system 828 associated with the computing device 1000 is loaded into the respective hard drive 830 and network adapter 836. The network can include copper wire, fiber optics, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers.

  Each set of external components 900 can include a computer display monitor 920, a keyboard 930, and a computer mouse 934. External components 900 can also include touch screens, virtual keyboards, touchpads, pointing devices, and other human interface devices. Each of the set of internal components 800 may also include a device driver 840 for interfacing with 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 including at least one processor coupled directly or indirectly to a memory element through a system bus. can do. The memory elements are, for example, local memory used during the actual execution of program code, mass storage, and at least some of them to reduce the number of times code must be fetched from mass storage during execution. A cache that temporarily stores program code. Includes memory.

  Input / output or I / O devices (including but not limited to keyboards, displays, pointing devices, DASD, 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 other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modems and Ethernet are just a few of the types of network adapters available.

  The present invention may 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 present invention.

  The computer readable storage medium may be a tangible device that can store and store instructions used by the instruction execution device. The computer-readable storage medium is, 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 do. As a non-exhaustive list of more specific examples of computer readable storage media, the following are: 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 in which instructions are recorded, and any suitable combination 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 temporary signal itself, such as an electrical signal transmitted through a wire.

  The computer readable program instructions described herein may be transmitted from a computer readable storage medium to a respective computer puting / processing device or a network such as, for example, the Internet, a local area network, a wide area network, and / or a wireless network. Can be downloaded to an external computer or an external storage device. The network can 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 computer-readable program instructions from the network and stores them in a computer-readable storage medium in the respective computing / processing device. Transfer instructions.

  Computer readable program instructions for performing the operations of the present invention include assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, millicode, firmware instructions, state setting data, or Java, Smalltalk, C ++. Sources written in any combination of one or more programming languages, including object oriented programming languages such as and the like, and conventional procedural programming languages such as "C" programming language or similar programming languages It can be either code or object code. The computer readable program instructions may be executed entirely on the user's computer, or may be executed in part on the user's computer as a stand-alone software package, and in part on the user's computer. Executed, some may be executed on a remote computer, or may be executed entirely 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 a wide area network (WAN), or connected to an external computer (E.g., via the Internet using an Internet service provider). In some embodiments, an electronic circuit including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) is used to implement a computer system to implement aspects of the invention. Computer readable program instructions can be executed by personalizing the electronic circuit using the state information of the readable program instructions.

  Aspects of the present 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 general purpose computer, special purpose computer, or other programmable data processing device processor to produce a machine and thereby executed by the computer or other programmable data processing device processor. The instructions may cause 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 that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, thereby providing instructions therein. Can be stored in a computer readable storage medium that manufactures a product that includes instructions that implement the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams.

  Computer program instructions are loaded onto a computer, other programmable data processing device, or other device, causing a series of operational steps to be performed on the computer, other programmable data processing device, or other device. A computer-implemented process whereby instructions executed on a computer or other programmable device, or other device, are designated by a function / specified in one or more blocks of the flowcharts and / or block diagrams. It is also possible to provide a process for performing the operation.

  The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of an instruction that includes one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions described in the blocks may be performed in a different order than the order described in the drawings. For example, two blocks shown in succession may actually be executed substantially simultaneously depending on the function involved, or sometimes the blocks are executed in reverse order. Also, each block in the block diagram and / or flowchart diagram, and combinations of blocks in the block diagram and / or flowchart diagram, may be associated with a dedicated hardware-based system that performs a specified function or operation, or with dedicated hardware. 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. Thus, 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 cache 118a, 118b: Data cache 120a, 120b: Interconnect control 122: Interconnect 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 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)

A method for predictively determining whether a HLE transaction actually acquires a lock and should be executed non-transactionally in a Hardware Lock Elision (HLE) environment, comprising:
Based on encountering the HLE lock-acquire instruction, based on the HLE predictor, determining whether to invalidate the lock and proceed as an HLE transaction, or to acquire the lock and proceed as a non-transaction. ,
Set the address of the lock as a read set for the HLE transaction, deter all writes to the lock by the lock-acquire instruction, and release the lock based on predicting that the HLE predictor will invalidate Proceed in HLE transaction execution mode until an xrelease instruction is encountered or until the HLE transaction encounters transaction contention;
Treating the HLE lock-acquire instruction as a non-HLE lock-acquire instruction and proceeding in non-transaction mode based on predicting that the HLE predictor does not invalidate;
Including methods.   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 lock address to zero based on first encountering an HLE transaction with the lock address;
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 lock address;
Incrementing the count of successful HLE transaction executions associated with the lock address of the HLE transaction in the HLE predictor based on completing any subsequent HLE transaction with the lock address. A high count of failed HLE transaction executions indicates a high probability of aborting, and incrementing;
The method of claim 1, further comprising: Monitoring in a non-transactional mode an attempt to access the lock by another process;
Incrementing the count of the failed HLE transaction execution upon detecting the access attempt by the other process;
The method of claim 1, further comprising: Tracking the count of successful HLE transaction executions and the count of failed HLE transaction executions within a time window;
Comparing the count of failed HLE transaction executions with 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 failed HLE transaction execution count exceeding the threshold number of failures;
The method of claim 1, further comprising:   6. The method of claim 5, further comprising resetting the successful HLE transaction execution count and the failed HLE transaction execution count to zero based on expiration of the time window. A computer program for predictively determining whether an HLE transaction should actually acquire a lock and execute non-transactionally in a Hardware Lock Elision (HLE) environment, the computer program comprising:
Based on encountering the HLE lock-acquire instruction, based on the HLE predictor, determining whether to invalidate the lock and proceed as an HLE transaction, or to acquire the lock and proceed as a non-transaction. ,
Set the address of the lock as a read set for the HLE transaction, deter all writes to the lock by the lock-acquire instruction, and release the lock based on predicting that the HLE predictor will invalidate Proceed in HLE transaction execution mode until an xrelease instruction is encountered or until the HLE transaction encounters transaction contention;
Treating the HLE lock-acquire instruction as a non-HLE lock-acquire instruction and proceeding in non-transaction mode based on predicting that the HLE predictor does not invalidate;
A computer program comprising instructions executed by a processing circuit for implementing a method comprising:   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 program according to claim 7. Monitoring in a non-transactional mode an attempt to access the lock by another process;
Incrementing the count of the failed HLE transaction execution upon detecting the access attempt by the other process;
The computer program according to claim 7, further comprising: Monitoring an attempt by another process to access the memory area protected by the lock in non-transactional mode;
Incrementing the count of the failed HLE transaction execution upon detecting the access attempt by the other process;
The computer program according to claim 7, further comprising: Initializing a count of successful HLE transaction executions associated with the lock address to zero based on first encountering an HLE transaction with the lock address;
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 lock address;
Incrementing the count of successful HLE transaction executions associated with the lock address of the HLE transaction in the HLE predictor based on completing any subsequent HLE transaction with the lock address. A high count of failed HLE transaction executions indicates a high probability of aborting, and incrementing;
The computer program according to claim 7, further comprising: Tracking the count of successful HLE transaction executions and the count of failed HLE transaction executions within a time window;
Comparing the count of failed HLE transaction executions with 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 failed HLE transaction execution count exceeding the threshold number of failures;
The computer program according to claim 7, further comprising:   13. The computer program product of claim 12, further comprising resetting the successful HLE transaction execution count and the failed HLE transaction execution count to zero based on expiration of the time window. A computer system for predictively determining whether an HLE transaction should actually acquire a lock and execute non-transactionally in a Hardware Lock Elision (HLE) environment, the computer system comprising:
Memory,
A processor in communication with the memory;
Including, and
Based on encountering the HLE lock-acquire instruction, based on the HLE predictor, determining whether to invalidate the lock and proceed as an HLE transaction, or to acquire the lock and proceed as a non-transaction. ,
Set the address of the lock as a read set for the HLE transaction, deter all writes to the lock by the lock-acquire instruction, and release the lock based on predicting that the HLE predictor will invalidate Proceed in HLE transaction execution mode until an xrelease instruction is encountered or until the HLE transaction encounters transaction contention;
Treating the HLE lock-acquire instruction as a non-HLE lock-acquire instruction and proceeding in non-transaction mode based on predicting that the HLE predictor does not invalidate;
A computer system configured to perform a method comprising:   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. Monitoring in a non-transactional mode an attempt to access the lock by another process;
Incrementing the count of the failed HLE transaction execution upon detecting the access attempt by the other process;
The computer system of claim 14, further comprising: Monitoring an attempt by another process to access the memory area protected by the lock in non-transactional mode;
Incrementing the count of the failed HLE transaction execution upon detecting the access attempt by the other process;
The computer system of claim 14, further comprising: Initializing a count of successful HLE transaction executions associated with the lock address to zero based on first encountering an HLE transaction with the lock address;
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 lock address;
Incrementing the count of successful HLE transaction executions associated with the lock address of the HLE transaction in the HLE predictor based on completing any subsequent HLE transaction with the lock address. A high count of failed HLE transaction executions indicates a high probability of aborting, and incrementing;
The computer system of claim 14, further comprising: Tracking the count of successful HLE transaction executions and the count of failed HLE transaction executions within a time window;
Comparing the count of failed HLE transaction executions with 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 failed HLE transaction execution count exceeding the threshold number of failures;
The computer system of claim 14, further comprising:   20. The computer system of claim 19, further comprising resetting the successful HLE transaction execution count and the failed HLE transaction execution count to zero based on expiration of the time window.

Images