JP2009508187A - Avoiding locks by executing critical sections transactionally - Google Patents

Abstract

A system that avoids locks by executing critical sections transactionally modifies the program as follows. (1) During transactional execution of a critical section, the program first determines whether the lock associated with the critical section is held by another process, and aborts transactional execution if held. (2) If the transactional execution completes without encountering an interfering data access from another process, the program commits the changes made during the transactional execution and the program's normal after the critical section Optionally resume non-transactional execution of. (3) If interfering data access from another process is encountered during transactional execution, the program discards the changes made during transactional execution and attempts to re-execute the critical section.

Description

  The present invention relates to a technique for improving performance in a computer system. More specifically, the present invention relates to a method and apparatus for avoiding the overhead associated with the use of locks by executing a critical section of code transactionally.

  Computer system designers are currently developing mechanisms to support multithreading in the latest generation of chip multiprocessors (CMP) as well as more traditional shared memory multiprocessors (SMPs). With proper hardware support, multithreading can dramatically increase the performance of many applications. However, as microprocessor performance continues to increase, the time spent synchronizing between threads (processes) has become a larger percentage of the overall execution time. In fact, this synchronization overhead becomes the dominant factor limiting application performance as multi-threaded applications begin to use even more threads.

  From the programmer's point of view, synchronization is usually achieved using locks. Locks are generally acquired before a thread enters the critical section of code and are released after the thread exits the critical section. If another thread wants to enter a critical section protected by the same lock, the other thread must acquire the same lock. If the lock cannot be acquired, the preceding thread has acquired the lock, and the thread must wait until the preceding thread releases the lock (the lock can be a number of operations such as atomic operations or semaphores). Note that it can be implemented in a manner).

  Unfortunately, the process of acquiring and unlocking locks requires a significant amount of time in modern microprocessors. They generally involve atomic operations that flush the load and store buffers, resulting in the need to complete hundreds, if not thousands, of processor cycles.

  In addition, multi-threaded applications require more locks in order to use more threads. For example, if a large number of threads need to access a shared data structure, using a single lock for all data structures is impractical for performance reasons. Instead, it is preferable to use multiple fine-grained locks to lock a small portion of the data structure. This allows many threads to operate in parallel on different parts of the data structure. However, a single thread also needs to acquire and release multiple locks to access different parts of the data structure. It also brings important software engineering concerns such as deadlock avoidance.

  In some cases, locks are used even when locks are not needed. For example, many applications make use of “thread-safe” library routines, which use locks to ensure that they are “thread-safe” for multi-threaded applications. Unfortunately, even when thread-safe library routines are called by single-threaded applications, the overhead associated with acquiring and releasing these locks still occurs.

  Applications typically use locks to ensure mutual exclusion within critical sections of code. However, in many cases, threads do not interfere with each other even when critical sections can be executed simultaneously. In these cases, mutual exclusion is used to prevent the unlikely case that threads actually interfere with each other. Therefore, in these cases, much of the overhead associated with acquiring and releasing locks is wasted.

  Therefore, there is a need for a method and apparatus that reduces the overhead associated with locking operations when accessing critical sections.

  One embodiment of the present invention provides a system that avoids locks by executing a critical section transactionally. During operation, the system receives a program that includes one or more critical sections that are protected by locks. The system then modifies the program so that the critical section protected by the lock is executed transactionally without acquiring the lock associated with the critical section.

  More specifically, the program is modified as follows. (1) During transactional execution of a critical section, the program first determines whether the lock associated with the critical section is held by another process, and if so, is executed transactionally. Abort. (2) If the transactional execution of the critical section completes without encountering interfering data access from another process, the program commits the changes made during the transactional execution and follows the critical section. (Optionally) resuming normal non-transactional execution of the program (the system can also consolidate many small transactions into large transactions, in which case the system Note that non-transactional execution after the section need not be resumed immediately). (3) During transactional execution of a critical section, if an interfering data access from another process is encountered, the program discards the changes made during transactional execution and zeros the critical section re-execution. Try more times.

  The step of checking the lock state during a transaction (step (1) above) allows the normal functioning of the transaction, along with other processing that actually acquires the lock before executing the critical section non-transactionally. Note that. This is advantageous because it allows the technology to be selectively applied when deemed useful, rather than an overall application where performance may be degraded in some cases.

  Note also that the code modification process can be performed manually. For example, programmers can identify frequently used critical sections, and make corresponding lock acquisition and unlock calls special calls and manuals that allow critical sections to be executed transactionally without acquiring locks. Can be replaced with

  In a variation of this embodiment, the step of modifying the program replaces the step of using a compiler to modify the program, the step of using a binary modification tool to modify the program, or a library accessed by the program. Steps.

  In the modification of this embodiment, it is allowed to proceed with data access from other processes during the transactional execution of the critical section.

  In a variation of this embodiment, attempting to re-execute the critical section includes attempting to re-execute the critical section transactionally.

  In a variation of this embodiment, if the critical section does not complete successfully after one or more attempts of transactional execution, the program acquires a lock associated with the critical section and makes the critical section non-transactional. The program is modified to execute and release the lock associated with the critical section.

  In a variation of this embodiment, the interfering data access can be stored by another process to a location loaded during transactional execution, loaded by another process to a location loaded during transactional execution, or transaction A store by another process to a location stored during a typical execution.

  In a variation of this embodiment, initiating transactional execution of the critical section includes performing a checkpointing operation to checkpoint register values and other state information.

  The following description is presented to enable any person skilled in the art to make and use the invention and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be used in other embodiments and applications without departing from the spirit and scope of the invention. Can be applied to. Accordingly, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

  The data structures and codes described in this detailed description are generally stored on a computer-readable storage medium, which can be any device or medium capable of storing code and / or data used by a computer system. possible. This includes computer instruction signals (signals) embodied in magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs), and DVDs (digital versatile discs or digital video discs), and transmission media. Including but not limited to a carrier to be modulated). For example, the transmission medium may include a communication network such as the Internet.

(Computer system)
FIG. 1 illustrates a computer system 100 according to an embodiment of the present invention. Computer system 100 may typically include any type of computer system, including a microprocessor-based computer system, a mainframe computer, a digital signal processor, a portable computing device, a personal organizer, a device controller, and an appliance. Including but not limited to the calculation engine. As shown in FIG. 1, the computer system 100 includes a level 2 (L2) cache 120 connected to a processor 101 and main memory (not shown). Since the processor 102 is similar in structure to the processor 101, only the processor 101 will be described below.

  The processor 101 has two register files 103 and 104, one of which is an “active register file” and the other is a backup “shadow register file”. In one embodiment of the present invention, processor 101 provides a flash copy operation that immediately copies all values from register file 103 to register file 104. This facilitates rapid register checkpointing operations and supports transactional execution.

  The processor 101 also includes one or more functional units, such as an adder 107 and a multiplier 108. These functional units are used in performing computer operations with operands retrieved from register file 103 or 104. Like conventional processors, load and store operations pass through load buffer 111 and store buffer 112.

  In addition, the processor 101 includes a level 1 (Ll) data cache 115 that stores data items that are likely to be used by the processor 101. Note that the line in the Ll data cache 115 includes a load marking bit 116 that indicates that a data value was loaded from the line during transactional execution. This load marking bit 116 is used to determine whether any interfering memory references occur during transactional execution, as will be described below with reference to FIGS. The processor 101 also includes an Ll instruction cache (not shown).

  Note that load marking does not necessarily have to occur in the Ll data cache 115. Typically, load marking can occur at any level of cache, such as L2 cache 120, or even in an independent structure. However, for performance reasons, load marking is likely to occur at a cache level as close as possible to the processor, which in this case is the Ll data cache 115. Otherwise, the load must go to the L2 cache 120 even on an L1 hit.

  The L2 cache 120 operates in cooperation with the Ll data cache 115 (and corresponding Ll instruction cache) in the processor 101, and operates in cooperation with the Ll data cache 117 (and corresponding Ll instruction cache) in the processor 102. . The L2 cache 120 was filed on June 26, 2002 by the inventors Shaylender Chaudhry and Mark Trembray (publication number US-2002-0199066-A1). Note that it is associated with a coherence mechanism 122, such as the inverted directory structure described in US patent application Ser. No. 10 / 186,118. The coherence mechanism 122 holds “copy back information” 121 for each cache line. This copyback information 121 facilitates transmission of the cache line from the L2 cache 120 to the requesting processor when the cache line must be transmitted to another processor.

  Each line in the L2 cache 120 includes a “store marking bit”, which indicates that a data value was stored in the line during transactional execution. This store marking bit is used to determine whether an interfering memory reference occurs during transactional execution, as described below with reference to FIGS. Note that store marking does not necessarily have to occur in the L2 cache 120.

  Ideally, store marking occurs at the cache level closest to the processor where the cache line is coherent. For the write-through Ll data cache, writes are automatically propagated to the L2 cache 120. However, if the Ll data cache is a write-back cache, store marking is performed on the Ll data cache (any other processor that later modifies the same cache line by the cache coherence protocol can be cached from the L1 cache. Note that the line will be taken out and the store mark will be recognized).

(Critical section execution)
FIG. 2A illustrates how a critical section is executed in accordance with an embodiment of the present invention. As shown on the left side of FIG. 2A, a thread executing a critical section generally acquires a lock associated with the critical section before entering the critical section. If another thread has acquired the lock, the thread must wait until the other thread releases the lock. Upon exiting the critical section, the thread releases the lock (note that the terms “thread” and “processing” are used interchangeably herein).

  Locks can be associated with shared data structures. For example, before accessing a shared data structure, a thread may acquire a lock on the shared data structure. The thread may then execute a critical section of code that accesses the shared data structure. When the thread completes access to the shared data structure, the thread releases the lock.

  In contrast, in the present invention, a thread does not acquire a lock, but instead executes a start transactional execution (STE) instruction before entering a critical section. If the critical section completes successfully without interference from other threads, the thread performs a commit operation to commit the changes made during the transaction execution. This series of events will be described in more detail below with reference to FIGS.

  Note that in one embodiment of the invention, the compiler replaces the lock acquisition instruction with an STE instruction and the corresponding unlock instruction with a commit instruction. Note that there may not be a one-to-one correspondence between replaced instructions. For example, a single lock acquisition operation consisting of multiple instructions can be replaced by a single STE instruction.

  Note that if for some reason it is not possible to proceed, it is often necessary to retain the ability to rely on locks. Also, from the viewpoint of software engineering, it is often desirable to convert the code only in the common path and leave the lock code as it is in the non-shared path. To facilitate this, when converting a critical section for transactional execution, lock acquisition can be replaced with an STE instruction, after which the lock state is read transactionally and the lock is not held. The code to confirm follows (see FIG. 2B).

  The above description assumes that the processor instruction set has been expanded to include STE and commit instructions. These instructions are described in more detail below with reference to FIGS.

(Transactional execution processing)
FIG. 3 is a flowchart illustrating how transactional execution occurs in accordance with an embodiment of the present invention. The thread first executes the STE instruction before entering the critical section of code (step 302). The system then executes the code transactionally within the critical section, but does not commit the result of the transactional execution (step 304).

  At the beginning of the transactional execution of the critical section, the program reads the lock state associated with the critical section transactionally to ensure that no lock is held. If the lock is held, the system aborts transactional execution (step 303). If another process has acquired the lock during the critical section transactional execution, the transactional execution of the critical section is aborted because the transactional read of the lock state is “interfered” by the lock acquisition operation. Keep in mind that

  During this transactional execution, the system continuously monitors data references by other threads to determine whether interfering data accesses (or other types of failures) occur during transactional execution. If not, the system automatically commits all changes made during transactional execution (step 308) and then optionally resumes normal non-transactional execution of the program after the critical section. (Step 310).

  Conversely, if interfering data access is detected, the system discards changes made during transactional execution (step 312) and attempts to re-execute the critical section (step 314).

  In one embodiment of the invention, the system attempts to re-execute the critical section transactionally zero times, once, twice, or more. If these attempts are not successful, the system executes the alternate code block in normal execution mode. This alternative code can make additional attempts to execute the transaction and has the ability to revert to conventional techniques to acquire a critical section lock before entering the critical section and release the lock after leaving the critical section. Can do.

  Note that an interfering data access may include a store by another thread to a cache line that has been load-marked by the thread. It may also include a load or store by another thread to a cache line that is store-marked by the thread.

  It is also noted that circuitry that detects interfering data accesses can be easily implemented by slightly modifying the conventional cache coherence circuitry. This conventional cache coherence network currently generates a signal that indicates whether a given cache line has been accessed by another processor. Thus, these signals can be used to determine whether an interfering data access has occurred.

(Start transactional execution)
FIG. 4 is a flowchart illustrating a start transactional execution (STE) operation according to an embodiment of the present invention. This flowchart shows what happens in step 302 of the flowchart of FIG. The system begins by checkpointing the register file (step 402). This includes performing a flash copy operation from the register file 103 to the register file 104 (see FIG. 1). In addition to checkpointing register values, this flash copy may also checkpoint various state registers associated with the executing thread. Normally, a flash copy operation checkpoints to a state where the corresponding thread can be resumed.

  At the same time, the register file is checkpointed and the STE operation causes the store buffer 112 to be in a “gate” state (step 404). This allows existing input in the store buffer to be propagated to the memory subsystem (and therefore committed to the processor architectural state), but new store buffer input generated during transactional execution Propagation is prevented.

  The system then initiates transactional execution including cache line load marking and store marking (step 406) and monitors data references to detect interfering references, if necessary.

(Road marking process)
FIG. 5 is a flowchart illustrating how load marking is performed during transactional execution in accordance with an embodiment of the present invention. During the transactional execution of a critical section, the system performs a load operation. When performing this load operation, if the load operation is identified as a load operation that needs to be load marked, the system first attempts to load a data item from the Ll data cache 115 (step 502). If a cache hit occurs due to the load, the system “load marks” the corresponding cache line in the Ll data cache 115 (step 506). This includes setting the load marking bit for the cache line. Alternatively, if the load causes a cache miss, the system retrieves the cache line from the further level of storage hierarchy (step 508) and proceeds to step 506 to load mark the cache line in the Ll data cache 115.

(Store marking process)
FIG. 6 is a flowchart illustrating how store marking is performed during transactional execution according to an embodiment of the present invention. During transactional execution of critical sections, the system performs store operations. If this store operation is identified as a store operation that needs to be store marked, the system first prefetches a dedicated corresponding cache line (step 602). Note that this prefetch operation does nothing if the line is already in the cache and already in a dedicated state.

  In this embodiment, the Ll data cache 115 is a write-through cache, and the store operation is propagated from the Ll data cache 115 to the L2 cache 120. Next, the system attempts to lock the cache line corresponding to the store operation in the L2 data cache 115 (step 604). If the corresponding line is in the L2 cache 120 (cache hit), the system “store marks” that corresponding cache line in the L2 cache 120 (step 610). This includes setting the store marking bit for the cache line. Alternatively, if the corresponding line is not in the L2 cache 120 (cache miss), the system retrieves the cache line from the further level storage hierarchy (step 608) and then proceeds to step 610 to cache in the L2 cache 120. Store mark the line.

  Next, when the cache line is store-marked in step 610, the system inputs store data to the input of the store buffer 112 (step 612). Note that this store data remains in the store buffer 112 until a subsequent commit operation occurs or until the transactionally executing change is discarded.

  Note that cache lines that are storemarked by a given thread can be read by other threads. Note that this may cause a given thread to fail while other threads can continue.

(Commit operation)
FIG. 7 is a flowchart illustrating how a commit operation is performed after a transactional execution has been successfully completed in accordance with an embodiment of the present invention. This flowchart shows what happens in step 308 of the flowchart of FIG.

  The system begins by processing store-marked cache lines as if they were locked (step 702). This means that other threads requesting the store-marked line will wait until the line is no longer locked before it can access the line. This is similar to the way lines are locked in a conventional cache.

  The system then deletes the load mark from the Ll data cache 115 (step 704).

  Next, the system commits the input from the store buffer 112 generated during transactional execution to the storage hierarchy for the store identified as needing to be marked (step 706). As each input is committed, the corresponding line in the L2 cache 120 is unlocked.

  The system also commits register file changes (step 708). For example, this may include functionally performing a flash copy between register file 103 and register file 104 in the system shown in FIG.

(Discard changes)
FIG. 8 is a flowchart illustrating how changes are discarded after a transactional execution has been unsuccessfully completed in accordance with an embodiment of the present invention. This flowchart shows what happens in step 312 of the flowchart of FIG. The system first discards the register file changes created during transactional execution (step 802). This may include erasing or simply ignoring register file changes made during transactional execution. This is easily accomplished because the old register values are checkpointed before the start of transactional execution. The system also deletes the load mark from the cache line in the Ll data cache 115 (step 804) and drains the store buffer input generated during transactional execution without committing to the storage hierarchy (step 806). ). At the same time, the system unmarks the corresponding L2 cache line. Finally, in one embodiment of the invention, the system branches to the target location specified by the STE instruction (step 808). At this target location, the code optionally attempts to re-execute the critical section (as described above with reference to step 314 in FIG. 1), or in response to a failure, such as a backoff to reduce contention. Take other actions.

  The foregoing descriptions of embodiments of the present invention have been presented only for purposes of illustration and description. They are not intended to be exhaustive or intended to limit the invention to the form disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in this art. Furthermore, the above disclosure is not intended to limit the present invention. The scope of the present invention is defined by the appended claims.

FIG. 1 illustrates a computer system according to an embodiment of the present invention. FIG. 2A illustrates how a critical section is executed in accordance with an embodiment of the present invention. FIG. 2B shows another example of how a critical section is executed according to an embodiment of the present invention. FIG. 3 is a flowchart illustrating transactional execution processing according to an embodiment of the present invention. FIG. 4 is a flowchart illustrating a start transactional execution (STE) operation according to an embodiment of the present invention. FIG. 5 is a flowchart illustrating how load marking is performed during transactional execution in accordance with an embodiment of the present invention. FIG. 6 is a flowchart illustrating how store marking is performed during transactional execution according to an embodiment of the present invention. FIG. 7 is a flowchart illustrating how a commit operation is performed according to an embodiment of the present invention. FIG. 8 is a flowchart illustrating how changes are discarded after a transactional execution has been unsuccessfully completed, in accordance with an embodiment of the present invention.

Claims (20)

A method for modifying a program to avoid locks by executing a critical section transactionally, the method comprising:
Receiving a program including one or more critical sections protected by a lock;
Modifying the program such that the critical section protected by a lock is executed transactionally without acquiring a lock associated with the critical section;
Including
The program
During transactional execution of a critical section, the program first determines whether the lock associated with the critical section is held by another process and, if so, aborts the transactional execution. ,
If the transactional execution of the critical section completes without encountering interfering data access from another process, the program commits the changes made during the transactional execution and Optionally resume normal non-transactional execution of the program after the section;
If, during the transactional execution of the critical section, an interfering data access from another process is encountered, the program discards the changes made during the transactional execution and re-executes the critical section. Try zero or more times to run,
To be corrected,
Method. The step of modifying the program includes
Using a compiler to modify the program;
Using a binary modification tool to modify the program;
Or replacing a library accessed by the program;
including,
The method of claim 1.   The method of claim 1, wherein data access from other processes is allowed to proceed during the transactional execution of the critical section.   The method of claim 1, wherein attempting to re-execute the critical section comprises attempting to re-execute the critical section transactionally. If the critical section does not complete successfully after one or more attempts of transactional execution, the program
Acquire a lock associated with the critical section;
Execute the critical section non-transactionally;
To release the lock associated with the critical section,
The program is modified,
The method of claim 4. The interfering data access is
A store with separate processing to the location loaded during transactional execution;
Load by another process to the location stored during transactional execution;
Store by another process to the location stored during transactional execution,
Can include,
The method of claim 1.   The method of claim 1, wherein initiating the transactional execution of a critical section comprises performing a checkpointing operation to checkpoint register values and other state information. A method for avoiding a lock by executing a critical section of code transactionally, the method comprising:
Allowing a process to transactionally execute a critical section of code in a program without acquiring a lock associated with the critical section;
Executing the critical section transactionally includes first determining whether the lock associated with the critical section is held in another process and, if held, the transactional execution. Cutting off, and
If the process completes the critical section without encountering interfering data access from another process, the method includes:
Committing changes made during the transactional execution;
Optionally resuming normal non-transactional execution of the program after the critical section; and
When encountering interfering data access from another process during transactional execution of the critical section, the method includes:
Discarding changes made during execution of the transaction;
Further attempting to re-execute the critical section zero or more times;
Method.   9. The method of claim 8, further comprising modifying the program such that a critical section protected by a lock is executed transactionally prior to executing the program. The step of modifying the program includes
Using a compiler to modify the program;
Using a binary modification tool to modify the program;
Or replacing a library accessed by the program;
including,
The method of claim 9.   9. The method of claim 8, wherein data access from other processes is allowed during the transactional execution of the critical section.   The method of claim 8, wherein attempting to re-execute the critical section comprises attempting to re-execute the critical section transactionally. If the critical section does not complete successfully after one or more attempts of transactional execution,
Obtaining a lock associated with the critical section;
Executing the critical section non-transactionally;
Releasing the lock associated with the critical section;
Further including,
The method of claim 12.   9. The method of claim 8, wherein initiating transactional execution of a critical section includes performing a checkpointing operation to checkpoint register values and other state information. The interfering data access is
Store by another process to where the process was loaded during transactional execution;
Loading by another process to the location where the process was stored during transactional execution;
Store by another process to where it was stored during transactional execution;
Can include,
The method of claim 8. An apparatus for modifying a program to avoid a lock by executing a critical section transactionally, the apparatus comprising:
A modification mechanism configured to modify the program such that a critical section protected by a lock is executed transactionally without acquiring a lock associated with the critical section;
The correction mechanism
During transactional execution of a critical section, the program first determines whether the lock associated with the critical section is held by another process and, if held, performs the transactional execution. Censored,
If the transactional execution of the critical section completes without encountering interfering data access from another process, the program commits the changes made during the transactional execution and Optionally resume normal non-transactional execution of the program after the section;
If interfering data access from another process is encountered during the transactional execution of the critical section, the program discards the changes made during the transactional execution and re-executes the critical section. To try zero or more times,
Configured to modify,
apparatus. The correction mechanism is:
compiler,
Binary correction tools,
Or a mechanism to replace a library accessed by the program,
Is,
The apparatus of claim 16.   The apparatus of claim 16, wherein data access from other processes is allowed to proceed during the transactional execution of the critical section.   The apparatus of claim 16, wherein attempting to re-execute the critical section comprises attempting to re-execute the critical section transactionally. If the critical section does not complete successfully after one or more attempts of transactional execution, the program
Acquire a lock associated with the critical section;
Execute the critical section non-transactionally;
To release the lock associated with the critical section,
The program is modified,
The apparatus of claim 19.

Images