US20070198978A1 - Methods and apparatus to implement parallel transactions - Google Patents
Methods and apparatus to implement parallel transactions Download PDFInfo
- Publication number
- US20070198978A1 US20070198978A1 US11/475,604 US47560406A US2007198978A1 US 20070198978 A1 US20070198978 A1 US 20070198978A1 US 47560406 A US47560406 A US 47560406A US 2007198978 A1 US2007198978 A1 US 2007198978A1
- Authority
- US
- United States
- Prior art keywords
- globally accessible
- shared data
- read
- data
- version information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
- G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
- G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
- G06F12/0815—Cache consistency protocols
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
- G06F12/0893—Caches characterised by their organisation or structure
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
- G06F9/526—Mutual exclusion algorithms
Definitions
- Parallelism is the practice of executing or performing multiple things simultaneously. Parallelism can be possible on multiple levels, from executing multiple instructions at the same time, to executing multiple threads at the same time, to executing multiple programs at the same time, and so on. Instruction Level Parallelism or ILP is parallelism at the lowest level and involves executing multiple instructions simultaneously. Processors that exploit ILP are typically called multiple-issue processors, meaning they can issue multiple instructions in a single clock cycle to the various functional units on the processor chip.
- One type of multiple-issue processor is a superscalar processor in which a sequential list of program instructions are dynamically scheduled. A respective processor determines which instructions can be executed on the same clock cycle, and sends them out to their respective functional units to be executed.
- This type of multi-issue processor is called an in-order-issue processor since issuance of instructions is performed in the same sequential order as the program sequence, but issued instructions may complete at different times (e.g., short instructions requiring fewer cycles may complete before longer ones requiring more cycles).
- VLIW Very Large Instruction Width
- a VLIW processor depends on a compiler to do all the work of instruction reordering and the processor executes the instructions that the compiler provides as fast as possible according to the compiler-determined order.
- Other types of multi-issue processors issue out of order instructions, meaning the instruction issue order is not be the same order as the order of instructions as they appear in the program.
- Another type of conventional parallel processing involves a use of fine-grain locking.
- fine-grain locking prevents conflicting instructions from being simultaneously executed in parallel based on use of lockouts. This technique therefore enables non-conflicting instructions to execute in parallel.
- embodiments herein include novel techniques for enhancing performance associated with transactions executing in parallel.
- a technique according to embodiments herein provides a unique way for each of multiple processes to operate in parallel using (e.g., based on reading, modifying, and writing to) a same set of shared data without causing corruption to the shared data.
- a computer system includes multiple processing threads that execute in parallel.
- the multiple processing threads have access to a global environment including i) shared data utilized by the multiple processing threads, ii) a globally accessible register or buffer of version information that changes each time a respective one of the multiple processing threads modifies the shared data, and iii) respective lock information indicating whether one of the multiple processing threads has locked the shared data preventing other processing threads from modifying the shared data.
- Each of the multiple processing threads accesses the version information (associated with the globally accessible shared data) and/or respective lock information at multiple times during execution of a respective processing thread to determine whether to abort execution of the respective processing thread as a result of another processing thread modifying the shared data. For example, if a given processing thread identifies (during a course of executing each of multiple successive reads) that another one of multiple processing threads modified the shared data or is currently modifying the shared data, the given processing thread aborts further operations and re-executes from the beginning again.
- respective processing threads notify each other of changes to the shared data is to update the respective version information associated with the shared data. For example, a respective processing thread can increment the version information after modifying contents of the shared data. If the given processing thread identifies that the version information is a first value at a respective time of a first read of shared data and a second value at a time of a second or subsequent read of shared data, then the given processing thread can immediately abort to end a respective transaction of multiple instructions.
- the lock information associated with the shared data also can be used to identify whether to abort a respective transaction.
- the lock information is a single lock bit value set and reset by the respective processing threads. Only one processing thread can obtain a lock over the shared data at a time.
- each of the multiple processing threads is initially optimistic that the corresponding processing thread will be able to complete a respective transaction prior to having to self-abort as a result of another processing thread contemporaneously modifying the shared data. If another processing thread modifies the shared data during the execution of a given processing thread, it can't be certain that the given processing thread and its results have not been corrupted. Self-aborting of a processing thread thus prevents potential corruption.
- a computerized device e.g., a host computer, workstation, etc.
- a computer environment can include a memory system, a processor (e.g., a processing device), a respective display, and an interconnect connecting the processor and the memory system.
- the interconnect can also support communications with the respective display (e.g., display screen or display medium).
- the memory system can be encoded with one or more applications that, when executed on a respective processor, supports parallel processing according to techniques herein.
- one embodiment herein includes a computer program product (e.g., a computer-readable medium).
- the computer program product includes computer program logic (e.g., software instructions) encoded thereon. Such computer instructions can be executed on a computerized device to support parallel processing according to embodiments herein.
- the computer program logic when executed on at least one processor associated with a computing system, causes the processor to perform the operations (e.g., the methods) indicated herein as embodiments of the present disclosure.
- Such arrangements as further disclosed herein can be provided as software, code and/or other data structures arranged or encoded on a computer readable medium such as an optical medium (e.g., CD-ROM), floppy or hard disk, or other medium such as firmware or microcode in one or more ROM or RAM or PROM chips or as an Application Specific Integrated Circuit (ASIC).
- the software or firmware or other such configurations can be installed on a computerized device to cause one or more processors in the computerized device to perform the techniques explained herein.
- Yet another more particular technique of the present disclosure is directed to a computer program product or computer environment that includes a computer readable medium having instructions stored thereon to facilitate use of shared information among multiple processes.
- Each of the multiple processes can support a technique of: i) initiating execution of a given processing thread including multiple instructions, the given processing thread producing a respective transaction outcome based on use of globally accessible shared data also accessible by other processing threads executing in parallel; ii) during execution of the given thread, initiate multiple reads of data from the globally accessible shared data for purposes of producing the transaction outcome; and iii) for each of the multiple reads, verify whether a respective globally accessible version information associated with the globally accessible shared data remains set to a constant value during execution of the given processing thread or portion thereof (such as from a first read to a next successive read), the globally accessible version information being changed to a new respective data value each time one of the processing threads modifies the globally accessible shared data.
- Other embodiments of the present disclosure include hardware and/or software programs to perform any of the method embodiment steps and operations summarize
- system of the invention can be embodied as a software program, as software and hardware, and/or as hardware alone.
- Example embodiments of the invention may be implemented within computer systems, processors, and computer program products and/or software applications manufactured by Sun Microsystems Inc. of Palo Alto, Calif., USA.
- FIG. 1 is a diagram illustrating a computer environment including multiple parallel processes that access shared data according to embodiments herein.
- FIG. 2 is a diagram of one of multiple processing threads utilizing a global accessible environment according to embodiments herein.
- FIG. 3 is a diagram of a sample architecture supporting shared use of data according to embodiments herein.
- FIG. 4 is a diagram of a flowchart illustrating a technique supporting simultaneous execution of multiple processing threads according to an embodiment herein.
- FIGS. 5 and 6 combine to form a flowchart illustrating a technique supporting simultaneous execution of multiple processing threads according to an embodiment herein.
- a computer system includes multiple processing threads that execute in parallel.
- the multiple processing threads have access to a global environment including i) shared data utilized by the multiple processing threads, ii) a globally accessible register or buffer of version information that changes each time a respective one of the multiple processing threads modifies the shared data, and iii) respective lock information indicating whether one of the multiple processing threads has locked the shared data preventing other processing threads from modifying the shared data.
- each of the processing threads monitors a status of the version information and the lock information during execution. If a given one of the multiple processing threads detects a change in the version information or another processing thread has a lock on the shared data, the given processing thread aborts and restarts execution again from the beginning. In one embodiment, each of the processes checks whether version information associated with shared content changes upon initiation of each of one or more successive read operations.
- This technique of aborting a given processing thread is well suited for use in parallel processing applications that support a high number of reads relative to a corresponding number of fewer respective writes to shared data. For example, when there are a fewer number of processing threads changing the shared data, there will be a fewer number of processing threads will need to abort a respective transaction as a result of changes to the shared data.
- FIG. 1 is a block diagram of a computer environment 100 according to an embodiment herein.
- computer environment 100 includes shared data 125 and corresponding metadata 135 in global environment 102 (e.g., a respective repository or global work environment) that is globally accessible by multiple processes 140 such as process 140 - 1 , process 140 - 2 , . . . process 140 -M.
- each of processes 140 e.g., processing threads
- metadata 135 enables each of processes 140 to identify whether content associated with shared data 125 has been “locked” (e.g., via checking lock information 120 - 2 ). Additionally, metadata 135 enables the processes 140 to identify whether any portions of shared data 125 have changed during execution of a respective transaction (e.g., via use of version information 120 - 1 ).
- version information 120 - 2 and version information 120 - 1 form lock-word.
- a lock-word is a shared global variables that contain version information 120 - 1 and a lock-bit information 120 - 2 .
- a given globally accessible shared data structure e.g., segment
- the lock-word is meta-data that moderates access to the shared data structure.
- Each of processes 140 competes to obtain a respective lock on shared data 125 .
- a given process writes a logic one to a respective lock bit of lock information 120 - 2 .
- processes 140 other than a respective process holding the lock are, by protocol, unable to modify contents of shared data 125 .
- M4 is a cooperative protocol. Threads use M4 to avoid races or undesirable interference. It's cooperative in the sense that all threads accessing the shared data will, by convention, use appropriate access protocol. (Nothing would stop an errant from accessing the data.
- the processes 140 can again compete to obtain a lock on shared data 125 .
- metadata 135 includes version information 120 - 1 that is updated each time a respective process modifies contents of shared data 125 . Accordingly, the processes 140 can monitor the version information to identify whether shared data 125 has been modified during a respective execution of a processing transaction (e.g., multiple software instructions).
- each of processes 140 stores an instantaneous data value (e.g., sampled version value or sampled version number) of current version information 120 - 1 in a respective local repository 110 at least some time during a respective execution of a transaction.
- the instantaneous data value is defined as a current value of the version information 120 - 1 at a time of reading. As discussed throughout this specific, this value changes over time as each of the processes 140 modifies the respective shared data 125 and updates this version information 120 - 1 to a new value.
- a respective process compares a data value associated with version information 120 - 1 in global environment 102 to the data value previously stored in its local repository 110 to identify whether another process 140 modified contents of shared data 125 . As will be discussed further in this specification, a respective process can abort itself and try again if version information 120 - 1 changes during respective execution.
- the above algorithm includes a single lock that protects all transactions.
- the technique herein e.g., a so-called M4 algorithm
- M4 algorithm is a read-write lock that provides automatic and transparent upgrade from read state to read-write state at the time of the 1st store in a transaction.
- the lock consists of a version field with the low-order bit serving as a write-lock.
- M4 here as a specific example of a locking algorithm it may be beneficial to switch with, but anyone skilled in the art will know how to make the described switching mechanism work for another mechanism that implements transactions by having a single lock protect all executed transactions.
- One embodiment of the M4 algorithm works as follows. We assume a read-write lock implemented using a single word, which we call the “lockword” (e.g., lock information 120 - 2 ) with a version field (e.g., version information 120 - 1 ).
- lockword e.g., lock information 120 - 2
- version field e.g., version information 120 - 1
- the thread saves the fetched lockword which contains the version subfield) into a thread-local variable and then executes the equested load.
- a transactional load can be carried out by first fetching data from memory and thereafter fetching (& validating) the version information. However, if this is a first load transaction, then the order of operation can include fetching the version information first, then fetching the shared data, and then fetching the version information again.
- CAS atomic Compare and Swap instruction
- a read set is a set of data locations read during a transaction.
- a write set is a set of data locations written to during a transaction as discussed in related applications. After a thread acquires the write-lock, it can simply store directly into the global fields without the need to save stores in a log file (e.g., a log file used for undo puporses). Likewise, loads don't need to look-aside into the store-log. Once the write-lock is acquired the operation can't abort.
- a classic read-write lock can't normally be upgraded or promoted from read to read-write state without the application having been explicitly and intentionally written to refresh any cached values seen during the read phase. That's because the read-write lock implementation might need to drop the lock to avoid deadlock during the upgrade to a read-write state.
- the M4 technique as described herein provides for automatic and transparent upgrade from a read-only lock to a read-write lock. M4 tends to be more profitable (e.g., more efficient) in circumstances where read-parallelism exists.
- VAL Validate-after-each-ld
- VAC validate-at-commit-time
- Transactional Load in VAL-mode if (the loading thread holds the write lock) then execute the load of the global variable as normal else if (this is 1st load in the thread's txn) then load lock-word if (lock-word lock-bit is set) then optionally spin, waiting for lock-bit to clear abort current txn else save previously fetched lock-word version into thread-local txn version variable execute the load of the global variable placing result in thread-local temporary variable load the lock-word if (the lock-word's lock-bit is set OR the lock-word's version # differs from the thread's txn version variable) then abort the txn. return the temporary variable (previously fetched value) as the result of the t
- VAC mode In VAL-mode we don't need to re-check the version at commit-time whereas we must validate the version at commit-time in VAC-mode. The differences between VAC and VAL boil down to when and where do we validate that the saved txn version remains unchanged. VAC mode moves validation from the txn LD operation to the commit operator and defers validation until commit-time. Recall that validation tells us if the previously read global variables are mutually consistent. VAL mode is the preferred embodiment as it doesn't admit so-called “zombie” transactions. A zombie is a transaction that has read inconsistent data and is doomed, but has yet to validate and abort.
- Zombies can misbehave, dereferencing illegal pointers, generating divide-by-zero traps, or entering infinite loops.
- VAC-mode is slightly more efficient, but admits zombies.
- Zombies require “containment” to prevent their misbehavior from effecting the rest of the system.
- VAL- and VAC-mode define two ends of a spectrum. Another valid scheme is to validate periodically during the txn—less frequently than at every txn load, but more frequently than just at commit-time. Critically, VAL mode is still more efficient than the read-set validation performed by previous software transactional memory implementations (STMs).
- FIG. 2 is a diagram more particularly illustrating details associated with a respective process according to embodiments herein.
- FIG. 2 illustrates read and write operations that can be performed by any one of the multiple processes 140 .
- each of the multiple processes 140 can simultaneously perform read operations.
- the processes 140 do not compete with each other to perform read type of operations.
- a respective process must obtain the lock before modifying or writing to contents of shared data 125 .
- Each of the multiple processes 140 can perform a respective read operation 205 - 1 to retrieve one or more data values associated with shared data 125 . Assume in this example that process 140 - 1 carries out read operation 205 - 1 . Note that each process 140 can operate in a similar manner.
- process 140 - 1 When carrying out such a read operation as illustrated in step 210 , process 140 - 1 first checks whether a respective lock bit associated with lock information 120 - 2 has been set by another process currently modifying shared data 125 . If the lock bit is not set, the respective process performs a first read of a portion (e.g., one or more locations) of shared data 125 .
- the respective process 140 - 1 initiates retrieval of respective version information 120 - 1 for storage in its corresponding local repository 110 - 1 (e.g., a buffer, register, allotted memory, etc.)
- the version information at a time of first read may be 000145.
- the process 140 - 1 stores this instantaneous data value of 000145 in its local repository 110 - 1 .
- the local repository can be a specific location of shared data assigned for use by only a respective process.
- the process eventually performs subsequent reads in step 220 .
- the process verifies that the lock bit is not set by another one of the multiple processes 140 .
- the process 140 - 1 checks whether a current value of the version information 120 - 1 has been modified since the last read. For example, the process 140 - 1 compares an instantaneous data value of the version information 120 - 1 at a time of the subsequent read and compares it to the data value stored in local repository 110 - 1 . If they match (e.g., the instantaneous data value of the version information 120 - 2 is still 000145), the process 140 - 1 can continue executing a respective transaction. If not, such as when the instantaneous data value of the version information 120 - 1 is 000146 indicating that another process modified shared data 125 , then the process 140 - 1 aborts the transaction and retries from the start.
- each of the processes 140 increments a respective value of the version information 120 - 1 upon committing corresponding results of a transaction to shared data 125 . In this latter case resulting in abortion, any intermediate data values generated by a respective processing thread prior to abortion are disregarded.
- a transactional load can be carried out by first fetching data from memory and thereafter fetching (& validating) the version information.
- the order of operation can include first fetching the version information, then fetching the shared data, and then fetching the version information again.
- Each of the processes 140 can also perform a write operation 205 - 2 .
- a write operation involves modifying contents of shared data 125 during a so-called write phase.
- the commit operation is a no-op.
- An M4 operation is guaranteed to commit normally (no aborts) if the thread manages to acquire (and validate) the M4 lock at the time of the 1st transactional write. If there are no writes in the transaction (e.g., it is a pure read transaction) then in VAL mode (as discussed above in FIG. 1 ) the respective process doesn't need to do anything, in VAC-mode process validates that the saved thread-local transaction version information still matches the version in the global lock-word.
- a respective process 140 - 1 can initially verify that current version information associated equals the instantaneous data value of version information 120 - 1 stored in its local repository 110 - 1 . As discussed above, the process can abort itself if the version information changes during a course of executing a respective processing thread or transaction.
- the process 140 - 1 also can retrieve the lock information 120 - 2 to identify whether another process currently has a lock on shared data 125 . If the lock bit is set, process 140 - 1 aborts a respective transaction. If the lock bit is not set, the process 140 - 1 sets the lock bit to an active state to obtain the lock over shared data 125 . Once a lock is obtained, no other processes can modify contents of shared data 125 .
- step 260 After obtaining a respective lock in step 260 , the process 140 - 1 initiates modification of shared data 125 according to a respective transaction outcome in step 260 .
- step 265 after modifying shared data 125 the process 140 - 1 updates the version information 120 - 1 with a new value (e.g., to a data value of 000146) and sets the lock bit (e.g., lock information 120 - 2 ) to an inactive state (e.g., the process releases a respective lock where the lock bit and version information are co-located in a single lock-word).
- the process 140 - 1 simultaneously sets a lock bit low at a same time of updating the version information 120 - 1 .
- FIG. 3 is a block diagram illustrating an example computer system 610 (e.g., an architecture associated with computer environment 100 ) for executing parallel processes 140 and other related processes according to embodiments herein.
- Computer system 610 can be a computerized device such as a personal computer, workstation, portable computing device, console, network terminal, processing device, etc.
- computer system 610 of the present example includes an interconnect 111 that couples a memory system 112 storing shared data 125 (e.g., globally accessible shared data), metadata 135 , one or more processors 113 executing processes 140 (e.g., process 140 - 1 , process 140 - 2 , . . . , process 140 -M), an I/O interface 114 , and a communications interface 115 .
- Peripheral devices 116 e.g., one or more optional user controlled devices such as a keyboard, mouse, display screens, etc.
- I/O interface 114 also enables computer system 610 to access repository 180 (that also potentially stores shared data 125 and/or metadata 135 ).
- Communications interface 115 enables computer system 610 to communicate over network 191 to transmit and receive information from different remote resources.
- each of processes 140 can be executed by the same processor 113 supporting parallel processing of processes 140 or executed by a different set of respective processors executing one or more of processes 140 .
- each of processes 140 executes a respective transaction associated with the same overall application.
- the processes 140 can be associated with different respective applications.
- functionality associated with processes 140 and/or computer environment 100 can be embodied as software code such as data and/or logic instructions (e.g., code stored in the memory or on another computer readable medium such as a disk) that support functionality according to different embodiments described herein.
- the functionality associated with processes 140 can be implemented via hardware or a combination of hardware and software code.
- Processor 113 can be one or multiple separate processors executing multiple processing threads.
- embodiments herein include a respective application and/or set of instructions to carry out processes 140 .
- Such a set of instructions associated with processes 140 can be stored on a computer readable medium such as a floppy disk, hard disk, optical medium, etc.
- the set of instruction can also be stored in a memory type system such as in firmware, RAM (Random Access Memory), read only memory (ROM), etc. or, as in this example, as executable code.
- FIG. 4 is a flowchart 400 illustrating a technique supporting execution of parallel transactions in computer environment 100 according to an embodiment herein. Note that techniques discussed in flowchart 400 overlap and summarize some of the techniques discussed above.
- a user or other source initiates execution of a given process (e.g., processing thread such as any one of processes 140 ) including multiple corresponding instructions.
- the given process produces a respective transaction outcome based on use of globally accessible shared data 125 also accessible by other processes 140 executing in parallel.
- step 420 during execution of the given process (e.g., processing thread), the given process initiates multiple reads of data from the globally accessible shared data 125 for purposes of producing the transaction outcome.
- the given process e.g., processing thread
- step 430 the given process 140 - 1 verifies whether an instantaneous data value associated with a respective globally accessible version information (e.g., version information 120 - 1 ) changes at a time from a first read to a next successive read.
- a respective globally accessible version information e.g., version information 120 - 1
- the globally accessible version information changes each time one of the process 140 modifies contents of the globally accessible shared data 125 .
- FIGS. 5 and 6 combine to form a flowchart 500 (e.g., flowchart 500 - 1 and flowchart 500 - 2 ) illustrating a technique supporting parallel execution of processes 140 according to embodiments herein. Note that techniques discussed in flowchart 500 overlap with the techniques discussed above in the previous figures.
- a given process (e.g., one of the multiple processing threads executing in parallel) performs a first read of data from globally accessible shared data 125 if there is no corresponding lock on the globally accessible shared data 125 .
- a corresponding lock if present, indicates that another one of the multiple processing threads is currently modifying the globally accessible shared data 125 .
- the given process stores a data value associated with the version information 120 - 1 (e.g., globally accessible version information) in a local buffer (e.g., a respective local repository 110 ) with respect to the given processing thread for the first read.
- a data value associated with the version information 120 - 1 e.g., globally accessible version information
- a local buffer e.g., a respective local repository 110
- step 520 for each subsequent read issued by the given process, the given process verifies that there is no lock on the globally accessible shared data 125 and that a corresponding data value of the version information 120 - 1 at a time of a respective subsequent read is identical to the data value stored in the local buffer for the first read the given processing thread is aborted if the version information 120 - 1 changes over time.
- step 525 after completing one or more subsequent reads and during a respective commit phase associated with the given process, the given process checks whether any one of the other processing threads currently has a lock on the globally accessible shared data 125 .
- the given process can further check whether a current data value associated with the version information 120 - 1 match the data value in its the local buffer. Recall that the data value in the local repository associated with the given process stores a respective data value of the version information for the first READ. At commit time, the current value of version information 120 - 1 should be the same as the data value in the local repository.
- step 530 if there is a lock as indicated by the checking or non-matching data value as indicated by the checking, the given process aborts the commit phase and re-executes the given process (e.g., transaction) again from the beginning. If few of the other processes 140 rarely initiate modification of shared data 125 , the given process will have a good chance of completing if re-executed again at a later time.
- step 610 of flowchart 500 - 2 of FIG. 6 if there is not a lock as indicated by the checking, the given process initiates a respective commit phase with respect to the given process.
- the given process carries out the following steps during a respective commit phase.
- step 615 of the write phase e.g., a period in a transaction from the first write until either abort or commit
- the given process obtains a respective lock on the globally accessible shared data 125 preventing the other processing threads from modifying the globally accessible shared data.
- the lock can be obtained by writing a logic one to a lock bit in lock information 120 - 2 .
- step 620 after obtaining the lock, the given process initiates modification of the globally accessible shared data 125 in accordance with the respective transaction outcome associated with the given process.
- step 625 after modification of globally accessible shared data 125 , the given process updates a respective data value associated with the version information to indicate to the other processing threads that the globally accessible shared data 125 has been modified. For example, if the data value of the version information 120 - 1 was 000145 before the modification, the process changes the version information to a data value of 000146.
- the given process releases the respective lock on the globally accessible shared data 125 .
- the given process resets the lock bit of lock information 120 - 2 to a logic zero.
- the given process updates the version information and releases the lock at the same time via a single operation (e.g., store operation).
Abstract
A computer system includes multiple processing threads that execute in parallel. The multiple processing threads have access to a global environment including i) shared data utilized by the multiple processing threads, ii) a globally accessible register or buffer of version information that changes each time a respective one of the multiple processing threads modifies the shared data, and iii) respective lock information indicating whether one of the multiple processing threads has locked the shared data preventing other processing threads from modifying the shared data. To prevent data corruption, each of the processing threads aborts if a given processing thread detects a change in the version information or another processing thread has a lock on the shared data. This technique is well suited for use in applications such as processing threads that support a high number of reads with a corresponding number of fewer respective writes to shared data.
Description
- This application claims the benefit of and priority to U.S. Provisional Patent Application Ser. No. 60/775,564 (Attorney's docket no. SUN06-01(060711)p, filed on Feb. 22, 2006, entitled “Switching Between Read-Write Locks and Transactional Locking,” the entire teachings of which are incorporated herein by this reference.
- This application is related to U.S. Patent Application identified by Attorney's docket no. SUN06-04(060720), filed on same date as the present application, entitled “METHODS AND APPARATUS TO IMPLEMENT PARALLEL TRANSACTIONS,” which itself claims the benefit of and priority to U.S. Provisional Patent Application Ser. No. 60/775,580 (Attorney's docket no. SUN06-02p(060720), filed on Feb. 22, 2006, entitled “Transactional Locking,” the entire teachings of which are incorporated herein by this reference.
- This application is related to U.S. Patent Application identified by Attorney's docket no. SUN06-06(060908), filed on same date as the present application, entitled “METHODS AND APPARATUS TO IMPLEMENT PARALLEL TRANSACTIONS,” which itself claims the benefit of and priority to U.S. Provisional Patent Application Ser. No. 60/789,843 (Attorney's docket no. SUN06-05(060908)p, filed on Apr. 5, 2006, entitled “Globally Versioned Transactional Locking,” the entire teachings of which are incorporated herein by this reference.
- This application is related to U.S. Patent Application identified by Attorney's docket no. SUN06-08(061191), filed on same date as the present application, entitled “METHODS AND APPARATUS TO IMPLEMENT PARALLEL TRANSACTIONS,” which itself claims the benefit of and priority to U.S. Provisional Patent Application Ser. No. 60/775,564 (Attorney's docket no. SUN06-01(060711)p, filed on Feb. 22, 2006, entitled “Switching Between Read-Write Locks and Transactional Locking,” the entire teachings of which are incorporated herein by this reference.
- There has been an ongoing trend in the information technology industry to execute software programs more quickly. For example, there are various conventional advancements that provide for increased execution speed of software programs.
- One technique for increasing execution speed of a program is called parallelism. Parallelism is the practice of executing or performing multiple things simultaneously. Parallelism can be possible on multiple levels, from executing multiple instructions at the same time, to executing multiple threads at the same time, to executing multiple programs at the same time, and so on. Instruction Level Parallelism or ILP is parallelism at the lowest level and involves executing multiple instructions simultaneously. Processors that exploit ILP are typically called multiple-issue processors, meaning they can issue multiple instructions in a single clock cycle to the various functional units on the processor chip.
- There are different types of conventional multiple-issue processors. One type of multiple-issue processor is a superscalar processor in which a sequential list of program instructions are dynamically scheduled. A respective processor determines which instructions can be executed on the same clock cycle, and sends them out to their respective functional units to be executed. This type of multi-issue processor is called an in-order-issue processor since issuance of instructions is performed in the same sequential order as the program sequence, but issued instructions may complete at different times (e.g., short instructions requiring fewer cycles may complete before longer ones requiring more cycles).
- Another type of multi-issue processor is called a VLIW (Very Large Instruction Width) processor. A VLIW processor depends on a compiler to do all the work of instruction reordering and the processor executes the instructions that the compiler provides as fast as possible according to the compiler-determined order. Other types of multi-issue processors issue out of order instructions, meaning the instruction issue order is not be the same order as the order of instructions as they appear in the program.
- Conventional techniques for executing instructions using ILP can utilize look-ahead techniques to find a larger amount of instructions that can execute in parallel within an instruction window. Looking-ahead often involves determining which instructions might depend upon others during execution for such things as shared variables, shared memory, interference conditions, and the like. When scheduling, a handler associated with the processor detects a group of instructions that do not interfere or depend on each other. The processor can then issue execution of these instructions in parallel thus conserving processor cycles and resulting in faster execution of the program.
- One type of conventional parallel processing involves a use of coarse-grained locking. As its name suggests, coarse-grained locking prevents conflicting groups of code from operating on different processes at the same time based on use of lockouts. Accordingly, this technique enables non-conflicting transactions or sets of instructions to execute in parallel.
- Another type of conventional parallel processing involves a use of fine-grain locking. As its name suggests, fine-grain locking prevents conflicting instructions from being simultaneously executed in parallel based on use of lockouts. This technique therefore enables non-conflicting instructions to execute in parallel.
- Conventional applications that support parallel processing can suffer from a number of deficiencies. For example, although easy to implement from the perspective of a software developer, coarse-grained locking techniques provide very poor performance because of limitations on parallelism. Although fine-grain lock-based concurrent software can perform exceptionally well during run-time, developing such code can be a very difficult task for a respective one or more software developers.
- Techniques discussed herein deviate with respect to conventional applications such as those discussed above as well as other techniques known in the prior art. For example, embodiments herein include novel techniques for enhancing performance associated with transactions executing in parallel.
- In general, a technique according to embodiments herein provides a unique way for each of multiple processes to operate in parallel using (e.g., based on reading, modifying, and writing to) a same set of shared data without causing corruption to the shared data. For example, according to one embodiment herein, a computer system includes multiple processing threads that execute in parallel. The multiple processing threads have access to a global environment including i) shared data utilized by the multiple processing threads, ii) a globally accessible register or buffer of version information that changes each time a respective one of the multiple processing threads modifies the shared data, and iii) respective lock information indicating whether one of the multiple processing threads has locked the shared data preventing other processing threads from modifying the shared data.
- Each of the multiple processing threads accesses the version information (associated with the globally accessible shared data) and/or respective lock information at multiple times during execution of a respective processing thread to determine whether to abort execution of the respective processing thread as a result of another processing thread modifying the shared data. For example, if a given processing thread identifies (during a course of executing each of multiple successive reads) that another one of multiple processing threads modified the shared data or is currently modifying the shared data, the given processing thread aborts further operations and re-executes from the beginning again.
- One way that respective processing threads notify each other of changes to the shared data is to update the respective version information associated with the shared data. For example, a respective processing thread can increment the version information after modifying contents of the shared data. If the given processing thread identifies that the version information is a first value at a respective time of a first read of shared data and a second value at a time of a second or subsequent read of shared data, then the given processing thread can immediately abort to end a respective transaction of multiple instructions.
- The lock information associated with the shared data also can be used to identify whether to abort a respective transaction. In one embodiment, the lock information is a single lock bit value set and reset by the respective processing threads. Only one processing thread can obtain a lock over the shared data at a time.
- Accordingly, each of the multiple processing threads is initially optimistic that the corresponding processing thread will be able to complete a respective transaction prior to having to self-abort as a result of another processing thread contemporaneously modifying the shared data. If another processing thread modifies the shared data during the execution of a given processing thread, it can't be certain that the given processing thread and its results have not been corrupted. Self-aborting of a processing thread thus prevents potential corruption.
- Techniques herein are well suited for use in applications such as processing threads that support a high number of reads and fewer respective writes to shared data because, in such an instance, one processing thread will rarely or less frequently (if at all) modify contents of the shared data and cause abortion of other processing threads. However, it should be noted that configurations herein are not limited to such use and thus configurations herein and deviations thereof are well suited for use in other environments as well.
- In addition to the embodiments discussed above, other embodiments herein include a computerized device (e.g., a host computer, workstation, etc.) configured to support the techniques disclosed herein such as use of a globally accessible version information enabling parallel execution of transaction performed by different processes. In such embodiments, a computer environment can include a memory system, a processor (e.g., a processing device), a respective display, and an interconnect connecting the processor and the memory system. The interconnect can also support communications with the respective display (e.g., display screen or display medium). The memory system can be encoded with one or more applications that, when executed on a respective processor, supports parallel processing according to techniques herein.
- Yet other embodiments of the present disclosure include software programs to perform the method embodiment and operations summarized above and disclosed in detail below in the Detailed Description section of this disclosure. More specifically, one embodiment herein includes a computer program product (e.g., a computer-readable medium). The computer program product includes computer program logic (e.g., software instructions) encoded thereon. Such computer instructions can be executed on a computerized device to support parallel processing according to embodiments herein.
- For example, the computer program logic, when executed on at least one processor associated with a computing system, causes the processor to perform the operations (e.g., the methods) indicated herein as embodiments of the present disclosure. Such arrangements as further disclosed herein can be provided as software, code and/or other data structures arranged or encoded on a computer readable medium such as an optical medium (e.g., CD-ROM), floppy or hard disk, or other medium such as firmware or microcode in one or more ROM or RAM or PROM chips or as an Application Specific Integrated Circuit (ASIC). The software or firmware or other such configurations can be installed on a computerized device to cause one or more processors in the computerized device to perform the techniques explained herein.
- Yet another more particular technique of the present disclosure is directed to a computer program product or computer environment that includes a computer readable medium having instructions stored thereon to facilitate use of shared information among multiple processes. Each of the multiple processes can support a technique of: i) initiating execution of a given processing thread including multiple instructions, the given processing thread producing a respective transaction outcome based on use of globally accessible shared data also accessible by other processing threads executing in parallel; ii) during execution of the given thread, initiate multiple reads of data from the globally accessible shared data for purposes of producing the transaction outcome; and iii) for each of the multiple reads, verify whether a respective globally accessible version information associated with the globally accessible shared data remains set to a constant value during execution of the given processing thread or portion thereof (such as from a first read to a next successive read), the globally accessible version information being changed to a new respective data value each time one of the processing threads modifies the globally accessible shared data. Other embodiments of the present disclosure include hardware and/or software programs to perform any of the method embodiment steps and operations summarized above and disclosed in detail below.
- It is to be understood that the system of the invention can be embodied as a software program, as software and hardware, and/or as hardware alone. Example embodiments of the invention may be implemented within computer systems, processors, and computer program products and/or software applications manufactured by Sun Microsystems Inc. of Palo Alto, Calif., USA.
- The foregoing and other objects, features, and advantages of the present application will be apparent from the following more particular description of preferred embodiments of the present disclosure, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, with emphasis instead being placed upon illustrating the embodiments, principles and concepts.
-
FIG. 1 is a diagram illustrating a computer environment including multiple parallel processes that access shared data according to embodiments herein. -
FIG. 2 is a diagram of one of multiple processing threads utilizing a global accessible environment according to embodiments herein. -
FIG. 3 is a diagram of a sample architecture supporting shared use of data according to embodiments herein. -
FIG. 4 is a diagram of a flowchart illustrating a technique supporting simultaneous execution of multiple processing threads according to an embodiment herein. -
FIGS. 5 and 6 combine to form a flowchart illustrating a technique supporting simultaneous execution of multiple processing threads according to an embodiment herein. - The present disclosure describes a unique way for each of multiple processes to operate in parallel using a common set of data (e.g., shared data) without causing corruption to the shared data. For example, as will be discussed in this specification, a computer system includes multiple processing threads that execute in parallel. The multiple processing threads have access to a global environment including i) shared data utilized by the multiple processing threads, ii) a globally accessible register or buffer of version information that changes each time a respective one of the multiple processing threads modifies the shared data, and iii) respective lock information indicating whether one of the multiple processing threads has locked the shared data preventing other processing threads from modifying the shared data.
- To prevent data corruption, each of the processing threads monitors a status of the version information and the lock information during execution. If a given one of the multiple processing threads detects a change in the version information or another processing thread has a lock on the shared data, the given processing thread aborts and restarts execution again from the beginning. In one embodiment, each of the processes checks whether version information associated with shared content changes upon initiation of each of one or more successive read operations.
- This technique of aborting a given processing thread is well suited for use in parallel processing applications that support a high number of reads relative to a corresponding number of fewer respective writes to shared data. For example, when there are a fewer number of processing threads changing the shared data, there will be a fewer number of processing threads will need to abort a respective transaction as a result of changes to the shared data.
-
FIG. 1 is a block diagram of acomputer environment 100 according to an embodiment herein. As shown,computer environment 100 includes shareddata 125 andcorresponding metadata 135 in global environment 102 (e.g., a respective repository or global work environment) that is globally accessible bymultiple processes 140 such as process 140-1, process 140-2, . . . process 140-M. In one embodiment, each of processes 140 (e.g., processing threads) has a correspondinglocal repository 110 for storing information such as an instantaneous value of version information 120-1 at different times during execution of a corresponding set of multiple instructions. - In the context of a general embodiment herein,
metadata 135 enables each ofprocesses 140 to identify whether content associated with shareddata 125 has been “locked” (e.g., via checking lock information 120-2). Additionally,metadata 135 enables theprocesses 140 to identify whether any portions of shareddata 125 have changed during execution of a respective transaction (e.g., via use of version information 120-1). - In one embodiment, version information 120-2 and version information 120-1 form lock-word. A lock-word is a shared global variables that contain version information 120-1 and a lock-bit information 120-2. A given globally accessible shared data structure (e.g., segment) is associated with only one lock-word. We say that lock-word protects or guards that data structure. The lock-word is meta-data that moderates access to the shared data structure.
- Each of
processes 140 competes to obtain a respective lock on shareddata 125. To obtain a lock preventing other processes from modifying shareddata 125, a given process writes a logic one to a respective lock bit of lock information 120-2. When set to a logic one, processes 140 other than a respective process holding the lock are, by protocol, unable to modify contents of shareddata 125. Critically, M4 is a cooperative protocol. Threads use M4 to avoid races or undesirable interference. It's cooperative in the sense that all threads accessing the shared data will, by convention, use appropriate access protocol. (Nothing would stop an errant from accessing the data. Upon release of a lock based on a respective process setting the lock bit to a logic zero, theprocesses 140 can again compete to obtain a lock on shareddata 125. - In addition to lock information 120-2,
metadata 135 includes version information 120-1 that is updated each time a respective process modifies contents of shareddata 125. Accordingly, theprocesses 140 can monitor the version information to identify whether shareddata 125 has been modified during a respective execution of a processing transaction (e.g., multiple software instructions). - In one embodiment, each of
processes 140 stores an instantaneous data value (e.g., sampled version value or sampled version number) of current version information 120-1 in a respectivelocal repository 110 at least some time during a respective execution of a transaction. Throughout this specific, the instantaneous data value is defined as a current value of the version information 120-1 at a time of reading. As discussed throughout this specific, this value changes over time as each of theprocesses 140 modifies the respective shareddata 125 and updates this version information 120-1 to a new value. - Some time after an initial load of version information 120-1 associated with shared
data 125, a respective process compares a data value associated with version information 120-1 inglobal environment 102 to the data value previously stored in itslocal repository 110 to identify whether anotherprocess 140 modified contents of shareddata 125. As will be discussed further in this specification, a respective process can abort itself and try again if version information 120-1 changes during respective execution. - Accordingly, the above algorithm includes a single lock that protects all transactions. Conceptually, the technique herein (e.g., a so-called M4 algorithm) is a read-write lock that provides automatic and transparent upgrade from read state to read-write state at the time of the 1st store in a transaction. The lock consists of a version field with the low-order bit serving as a write-lock. We describe M4 here as a specific example of a locking algorithm it may be beneficial to switch with, but anyone skilled in the art will know how to make the described switching mechanism work for another mechanism that implements transactions by having a single lock protect all executed transactions.
- One embodiment of the M4 algorithm works as follows. We assume a read-write lock implemented using a single word, which we call the “lockword” (e.g., lock information 120-2) with a version field (e.g., version information 120-1).
- 1. According to One Embodiment, on a Transactional Load:
- (a) if the loading thread holds the write-lock the load simply executes the load as normal.
- (b) If the thread doesn't hold the write-lock it loads the lockword.
- i. If the lockword indicates that some other thread holds the write-lock, the reading thread aborts immediately and retries.
- ii. Otherwise:
- A. if this is the 1st transactional load, the thread saves the fetched lockword which contains the version subfield) into a thread-local variable and then executes the equested load.
- B. If this is not the 1st transactional load the thread checks the just-loaded version against the version saved in the thread's thread-local variable. If they disagree then the thread aborts immediately, otherwise the load executes as normal.
- Note that the last two steps A and B can be modified to carry yet another embodiment herein. For example, in one embodiment, a transactional load can be carried out by first fetching data from memory and thereafter fetching (& validating) the version information. However, if this is a first load transaction, then the order of operation can include fetching the version information first, then fetching the shared data, and then fetching the version information again.
- 2. According to One Embodiment, on a Transactional Store:
- (a) if the storing thread already holds the write-lock, the store executes normally.
- (b) if the storing thread does not hold the write-lock:
- i. If there was a previous transactional load, the thread attempts to CAS (atomic Compare and Swap instruction) the write-lock bit with the previously observed version. If the CAS is successful the thread now holds the write-lock and the store executes normal. If the CAS fails then the transaction aborts immediately.
- ii. If there was no prior transactional load in this transaction the thread loops, trying to toggle the low-order write-lock bit in the lockword from 0 to 1. Once the thread has acquired the write-lock it executes the store or write operation.
- According to the M4 technique, there's no need to track read-sets or write-sets so the overhead is quite low. A read set is a set of data locations read during a transaction. A write set is a set of data locations written to during a transaction as discussed in related applications. After a thread acquires the write-lock, it can simply store directly into the global fields without the need to save stores in a log file (e.g., a log file used for undo puporses). Likewise, loads don't need to look-aside into the store-log. Once the write-lock is acquired the operation can't abort.
- In a related manner (since there's only one lock) there's no possibility of livelock or deadlock. A classic read-write lock can't normally be upgraded or promoted from read to read-write state without the application having been explicitly and intentionally written to refresh any cached values seen during the read phase. That's because the read-write lock implementation might need to drop the lock to avoid deadlock during the upgrade to a read-write state. The M4 technique as described herein provides for automatic and transparent upgrade from a read-only lock to a read-write lock. M4 tends to be more profitable (e.g., more efficient) in circumstances where read-parallelism exists.
- Consider, for example, a hash table where most operations are queries. According to M4, pure readers may operate completely in parallel. Furthermore, the readers do not need to store into a shared location to acquire a lock. Note that traditional SMP systems use snoop- or directory-based cache coherency protocols, concurrent sharing of or access to cache lines tend to incur high latency and consume precious coherency bandwidth if stores to the shared line are frequent. Pure read sharing, however, is typically inexpensive.
- Furthermore, A number of variations are possible and it'll pay to enumerate them in the application. To keep things straight I'll call them Validate-after-each-ld (VAL) and validate-at-commit-time (VAC).
Transactional Load in VAL-mode: if (the loading thread holds the write lock) then execute the load of the global variable as normal else if (this is 1st load in the thread's txn) then load lock-word if (lock-word lock-bit is set) then optionally spin, waiting for lock-bit to clear abort current txn else save previously fetched lock-word version into thread-local txn version variable execute the load of the global variable placing result in thread-local temporary variable load the lock-word if (the lock-word's lock-bit is set OR the lock-word's version # differs from the thread's txn version variable) then abort the txn. return the temporary variable (previously fetched value) as the result of the txn load -
Transactional load in VAC-mode: if (the loading thread holds the write lock) then execute the load of the global variable as normal else if (this is 1st load in the thread's txn) then load lock-word if (lock-word lock-bit is set) then optionally spin, waiting for lock-bit to clear abort current txn else save lock-word version into thread-local txn version variable execute the load of the global variable as normal - In VAL-mode we don't need to re-check the version at commit-time whereas we must validate the version at commit-time in VAC-mode. The differences between VAC and VAL boil down to when and where do we validate that the saved txn version remains unchanged. VAC mode moves validation from the txn LD operation to the commit operator and defers validation until commit-time. Recall that validation tells us if the previously read global variables are mutually consistent. VAL mode is the preferred embodiment as it doesn't admit so-called “zombie” transactions. A zombie is a transaction that has read inconsistent data and is doomed, but has yet to validate and abort. Zombies can misbehave, dereferencing illegal pointers, generating divide-by-zero traps, or entering infinite loops. VAC-mode is slightly more efficient, but admits zombies. Zombies require “containment” to prevent their misbehavior from effecting the rest of the system.
- Note that VAL- and VAC-mode define two ends of a spectrum. Another valid scheme is to validate periodically during the txn—less frequently than at every txn load, but more frequently than just at commit-time. Critically, VAL mode is still more efficient than the read-set validation performed by previous software transactional memory implementations (STMs).
-
FIG. 2 is a diagram more particularly illustrating details associated with a respective process according to embodiments herein. For clarity sake,FIG. 2 illustrates read and write operations that can be performed by any one of themultiple processes 140. For example, each of themultiple processes 140 can simultaneously perform read operations. In general, theprocesses 140 do not compete with each other to perform read type of operations. However, a respective process must obtain the lock before modifying or writing to contents of shareddata 125. - Each of the
multiple processes 140 can perform a respective read operation 205-1 to retrieve one or more data values associated with shareddata 125. Assume in this example that process 140-1 carries out read operation 205-1. Note that eachprocess 140 can operate in a similar manner. - When carrying out such a read operation as illustrated in
step 210, process 140-1 first checks whether a respective lock bit associated with lock information 120-2 has been set by another process currently modifying shareddata 125. If the lock bit is not set, the respective process performs a first read of a portion (e.g., one or more locations) of shareddata 125. - In
step 215, the respective process 140-1 initiates retrieval of respective version information 120-1 for storage in its corresponding local repository 110-1 (e.g., a buffer, register, allotted memory, etc.) For example, the version information at a time of first read may be 000145. The process 140-1 stores this instantaneous data value of 000145 in its local repository 110-1. Note that the local repository can be a specific location of shared data assigned for use by only a respective process. - The process eventually performs subsequent reads in
step 220. For each subsequent read of shareddata 125, the process verifies that the lock bit is not set by another one of themultiple processes 140. Additionally, the process 140-1 checks whether a current value of the version information 120-1 has been modified since the last read. For example, the process 140-1 compares an instantaneous data value of the version information 120-1 at a time of the subsequent read and compares it to the data value stored in local repository 110-1. If they match (e.g., the instantaneous data value of the version information 120-2 is still 000145), the process 140-1 can continue executing a respective transaction. If not, such as when the instantaneous data value of the version information 120-1 is 000146 indicating that another process modified shareddata 125, then the process 140-1 aborts the transaction and retries from the start. - Note that in one embodiment, each of the
processes 140 increments a respective value of the version information 120-1 upon committing corresponding results of a transaction to shareddata 125. In this latter case resulting in abortion, any intermediate data values generated by a respective processing thread prior to abortion are disregarded. - Note that the
steps 210 through 220 can be modified to carry yet another embodiment herein. For example, in one embodiment, a transactional load can be carried out by first fetching data from memory and thereafter fetching (& validating) the version information. However, for a respective first load transaction, the order of operation can include first fetching the version information, then fetching the shared data, and then fetching the version information again. - Each of the
processes 140 can also perform a write operation 205-2. A write operation involves modifying contents of shareddata 125 during a so-called write phase. At the write-time in M4, if there were any prior writes in the thread's transaction, then the current thread must hold the write-lock. In this case the commit operation is a no-op. An M4 operation is guaranteed to commit normally (no aborts) if the thread manages to acquire (and validate) the M4 lock at the time of the 1st transactional write. If there are no writes in the transaction (e.g., it is a pure read transaction) then in VAL mode (as discussed above inFIG. 1 ) the respective process doesn't need to do anything, in VAC-mode process validates that the saved thread-local transaction version information still matches the version in the global lock-word. - For example, in
step 255, a respective process 140-1 can initially verify that current version information associated equals the instantaneous data value of version information 120-1 stored in its local repository 110-1. As discussed above, the process can abort itself if the version information changes during a course of executing a respective processing thread or transaction. - The process 140-1 also can retrieve the lock information 120-2 to identify whether another process currently has a lock on shared
data 125. If the lock bit is set, process 140-1 aborts a respective transaction. If the lock bit is not set, the process 140-1 sets the lock bit to an active state to obtain the lock over shareddata 125. Once a lock is obtained, no other processes can modify contents of shareddata 125. - After obtaining a respective lock in
step 260, the process 140-1 initiates modification of shareddata 125 according to a respective transaction outcome instep 260. - In
step 265, after modifying shareddata 125 the process 140-1 updates the version information 120-1 with a new value (e.g., to a data value of 000146) and sets the lock bit (e.g., lock information 120-2) to an inactive state (e.g., the process releases a respective lock where the lock bit and version information are co-located in a single lock-word). In one embodiment, the process 140-1 simultaneously sets a lock bit low at a same time of updating the version information 120-1. -
FIG. 3 is a block diagram illustrating an example computer system 610 (e.g., an architecture associated with computer environment 100) for executingparallel processes 140 and other related processes according to embodiments herein.Computer system 610 can be a computerized device such as a personal computer, workstation, portable computing device, console, network terminal, processing device, etc. - As shown,
computer system 610 of the present example includes aninterconnect 111 that couples amemory system 112 storing shared data 125 (e.g., globally accessible shared data),metadata 135, one ormore processors 113 executing processes 140 (e.g., process 140-1, process 140-2, . . . , process 140-M), an I/O interface 114, and acommunications interface 115. Peripheral devices 116 (e.g., one or more optional user controlled devices such as a keyboard, mouse, display screens, etc.) can couple toprocessor 113 through I/O interface 114. I/O interface 114 also enablescomputer system 610 to access repository 180 (that also potentially stores shareddata 125 and/or metadata 135). Communications interface 115 enablescomputer system 610 to communicate overnetwork 191 to transmit and receive information from different remote resources. - Note that each of
processes 140 can be executed by thesame processor 113 supporting parallel processing ofprocesses 140 or executed by a different set of respective processors executing one or more ofprocesses 140. In one embodiment, each ofprocesses 140 executes a respective transaction associated with the same overall application. However, theprocesses 140 can be associated with different respective applications. - Further note that functionality associated with
processes 140 and/orcomputer environment 100 can be embodied as software code such as data and/or logic instructions (e.g., code stored in the memory or on another computer readable medium such as a disk) that support functionality according to different embodiments described herein. Alternatively, the functionality associated withprocesses 140 can be implemented via hardware or a combination of hardware and software code.Processor 113 can be one or multiple separate processors executing multiple processing threads. - It should be noted that, in addition to the
processes 140 themselves, embodiments herein include a respective application and/or set of instructions to carry outprocesses 140. Such a set of instructions associated withprocesses 140 can be stored on a computer readable medium such as a floppy disk, hard disk, optical medium, etc. The set of instruction can also be stored in a memory type system such as in firmware, RAM (Random Access Memory), read only memory (ROM), etc. or, as in this example, as executable code. - Collective attributes associated with
processes 140,global environment 102, andcomputer environment 100, etc. will now be discussed with respect to flowcharts inFIGS. 4-6 . For purposes of this discussion,global environment 102,processes 140 and/orcomputer environment 100 can execute or carry out the steps described in the respective flowcharts. Note that the steps in the below flowcharts need not always be executed in the order shown. - Now, more particularly,
FIG. 4 is aflowchart 400 illustrating a technique supporting execution of parallel transactions incomputer environment 100 according to an embodiment herein. Note that techniques discussed inflowchart 400 overlap and summarize some of the techniques discussed above. - In
step 410, a user or other source initiates execution of a given process (e.g., processing thread such as any one of processes 140) including multiple corresponding instructions. The given process produces a respective transaction outcome based on use of globally accessible shareddata 125 also accessible byother processes 140 executing in parallel. - In
step 420, during execution of the given process (e.g., processing thread), the given process initiates multiple reads of data from the globally accessible shareddata 125 for purposes of producing the transaction outcome. - In
step 430, the given process 140-1 verifies whether an instantaneous data value associated with a respective globally accessible version information (e.g., version information 120-1) changes at a time from a first read to a next successive read. As previously discussed, the globally accessible version information (version information 120-1) changes each time one of theprocess 140 modifies contents of the globally accessible shareddata 125. -
FIGS. 5 and 6 combine to form a flowchart 500 (e.g., flowchart 500-1 and flowchart 500-2) illustrating a technique supporting parallel execution ofprocesses 140 according to embodiments herein. Note that techniques discussed in flowchart 500 overlap with the techniques discussed above in the previous figures. - In
step 510, a given process (e.g., one of the multiple processing threads executing in parallel) performs a first read of data from globally accessible shareddata 125 if there is no corresponding lock on the globally accessible shareddata 125. A corresponding lock, if present, indicates that another one of the multiple processing threads is currently modifying the globally accessible shareddata 125. - In
step 515, the given process stores a data value associated with the version information 120-1 (e.g., globally accessible version information) in a local buffer (e.g., a respective local repository 110) with respect to the given processing thread for the first read. - In
step 520, for each subsequent read issued by the given process, the given process verifies that there is no lock on the globally accessible shareddata 125 and that a corresponding data value of the version information 120-1 at a time of a respective subsequent read is identical to the data value stored in the local buffer for the first read the given processing thread is aborted if the version information 120-1 changes over time. - In
step 525, after completing one or more subsequent reads and during a respective commit phase associated with the given process, the given process checks whether any one of the other processing threads currently has a lock on the globally accessible shareddata 125. In one embodiment, the given process can further check whether a current data value associated with the version information 120-1 match the data value in its the local buffer. Recall that the data value in the local repository associated with the given process stores a respective data value of the version information for the first READ. At commit time, the current value of version information 120-1 should be the same as the data value in the local repository. - In
step 530, if there is a lock as indicated by the checking or non-matching data value as indicated by the checking, the given process aborts the commit phase and re-executes the given process (e.g., transaction) again from the beginning. If few of theother processes 140 rarely initiate modification of shareddata 125, the given process will have a good chance of completing if re-executed again at a later time. - In
step 610 of flowchart 500-2 ofFIG. 6 , if there is not a lock as indicated by the checking, the given process initiates a respective commit phase with respect to the given process. In one embodiment, the given process carries out the following steps during a respective commit phase. - For example, in
step 615 of the write phase (e.g., a period in a transaction from the first write until either abort or commit), the given process obtains a respective lock on the globally accessible shareddata 125 preventing the other processing threads from modifying the globally accessible shared data. As previously discussed, the lock can be obtained by writing a logic one to a lock bit in lock information 120-2. - In
step 620, after obtaining the lock, the given process initiates modification of the globally accessible shareddata 125 in accordance with the respective transaction outcome associated with the given process. - In
step 625, after modification of globally accessible shareddata 125, the given process updates a respective data value associated with the version information to indicate to the other processing threads that the globally accessible shareddata 125 has been modified. For example, if the data value of the version information 120-1 was 000145 before the modification, the process changes the version information to a data value of 000146. - In
step 630, the given process releases the respective lock on the globally accessible shareddata 125. For example, the given process resets the lock bit of lock information 120-2 to a logic zero. In one embodiment, the given process updates the version information and releases the lock at the same time via a single operation (e.g., store operation). - As discussed above, techniques herein are well suited for use in applications such as those that support parallel processing threads in the same processor or in different processors. However, it should be noted that configurations herein are not limited to such use and thus configurations herein and deviations thereof are well suited for use in other environments as well.
- While this invention has been particularly shown and described with references to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present application as defined by the appended claims. Such variations are covered by the scope of this present disclosure. As such, the foregoing description of embodiments of the present application is not intended to be limiting. Rather, any limitations to the invention are presented in the following claims. Note that the different embodiments disclosed herein can be combined or utilized individually with respect to each other.
Claims (20)
1. A method comprising:
initiating execution of a given processing thread including multiple instructions, the given processing thread producing a respective transaction outcome based on use of globally accessible shared data also accessible by other processing threads executing in parallel;
during execution of the given thread, initiating multiple reads of data from the globally accessible shared data for purposes of producing the transaction outcome; and
verifying whether a data value associated with a respective globally accessible version information variable changes at a time from a first read to a next successive read during a course of a transaction, the globally accessible version information variable being changed to a new respective data value each time one of the processing threads modifies contents of the globally accessible shared data.
2. A method as in claim 1 , wherein verifying whether the respective globally accessible version information variable changes over successive reads enables the given processing thread to efficiently detect whether any of the other processing threads modified the contents of the globally accessible shared data during execution of the given thread from the first read to the next successive read.
3. A method as in claim 2 further comprising:
detecting that another processing thread modified contents of the globally accessible shared data during a respective time between the first read and the next successive read based on a change with respect to the globally accessible version information variable; and
in response to detecting the change, immediately aborting execution of the given processing thread.
4. A method as in claim 1 , wherein verifying whether the respective globally accessible version information variable changes from the first read to the next successive read includes:
initiating the first read to retrieve respective data from the globally accessible shared data;
for the first read, retrieving and storing a respective data value associated with the globally accessible version information variable;
at a later time with respect to the first read, initiating the next successive read to retrieve respective data from the globally accessible shared data;
for the next successive read, retrieving a respective data value associated with the globally accessible version information variable; and
verifying that the respective data value of the globally accessible version information variable for the first read is identical to the respective data value of the globally accessible version information variable for the next successive read.
5. A method as in claim 1 further comprising:
for the given processing thread, performing the first read of data from the globally accessible shared data if there is no corresponding lock on the globally accessible shared data, the corresponding lock, if present, indicating that another one of the multiple processing threads is in a process of modifying the globally accessible shared data;
for the first read, storing a data value associated with the globally accessible version information variable in a local buffer with respect to the given processing thread;
for each subsequent read associated with the given processing thread, verifying that there is no lock on the globally accessible shared data and that a corresponding data value of the globally accessible version information variable at a time of a respective subsequent read is identical to the data value stored in the local buffer for the first read; and
initiating abortion of the given processing thread if there is a lock on the globally accessible shared data or if a respective data value associated with the globally accessible version information variable changes from the first read to a subsequent read.
6. A method as in claim 5 further comprising:
aborting further execution of the given processing thread if there is a corresponding lock on the globally accessible shared data, the corresponding lock indicating that another one of the multiple processing threads is in a process of modifying the globally accessible shared data.
7. A method as in claim 1 further comprising:
upon completion of the execution of the processing thread including the multiple reads, initiating storage of at least one data value associated with the respective transaction outcome to the globally accessible shared data;
prior to storage of the at least one data value to the globally accessible shared data, checking whether any of the other processing threads currently has a lock on the globally accessible shared data, presence of the lock indicating that another one of the multiple processing threads is in a process of modifying the globally accessible shared data; and
aborting the processing thread and corresponding storage of the at least one data value to the globally accessible shared data.
8. A method as in claim 1 further comprising:
prior to committing data values associated with the processing thread to the globally accessible shared data during a respective commit phase of the given processing thread, checking whether a current value of the globally accessible version information variable matches the constant value encountered from the first read to the next successive read; and
aborting the given processing thread if there is not a match between the current value of the globally accessible version information variable and the constant value encountered during the first read to the next successive read.
9. A method as in claim 1 further comprising:
checking whether any one of the other processing threads currently has a lock on the globally accessible shared data;
if there is a lock as indicated by the checking, then abort and re-execute the given processing thread;
if there is not a lock as indicated by the checking, initiating a respective commit phase with respect to the given processing thread, the commit phase including:
i) obtaining a respective lock on the globally accessible shared data preventing the other processing threads from modifying the globally accessible shared data,
ii) initiate modification of the globally accessible shared data in accordance with the respective transaction outcome associated with the given processing thread, and
iii) after the modification of globally accessible shared data, updating a respective data value associated with the globally accessible version information variable to indicate to the other processing threads that the globally accessible shared data has been modified.
10. A method as in claim 9 , wherein the commit phase further comprises:
iv) releasing the respective lock on the globally accessible shared data at a same time as updating the respective data value associated with the globally accessible version information variable to a new value.
11. A computer system including:
multiple processing threads executing in parallel;
a global environment accessible by the multiple processing threads, the global environment including i) shared data utilized by the multiple processing threads, ii) version information that changes each time a respective one of the multiple processing threads modifies the shared data, and iii) respective lock information indicating whether one of the multiple processing threads has locked the shared data preventing other processing threads from modifying the shared data; and
each of the multiple processing threads accessing the version information at multiple times during execution of a respective processing thread to determine whether to abort execution of the respective processing thread as a result of another processing thread modifying the shared data.
12. A computer system as in claim 11 , wherein the respective processing thread initiates retrieval of an instantaneous data value associated with the version information at a time of a first read of data from the set of shared data and checks whether the instantaneous data value for the first read matches an instantaneous data value of the version information at a time of a second read of data from the set of shared data, a respective match of the instantaneous data values indicating that no other processing thread modified contents of the shared data during execution of the respective processing thread.
13. A computer system as in claim 11 , wherein each of the multiple processes continues to execute as long as the version information associated with the set of shared data does not change but otherwise abort if the respective processing thread identifies that the version information associated with the set of shared data changes over time.
14. A computer system as in claim 13 , wherein each of the respective processing threads checks for changes associated with the version information each time the respective processing thread performs a respective successive read from the set of shared data.
15. A computer readable medium including:
instructions associated with a given processing thread that produces a respective transaction outcome based on use of globally accessible shared data also accessible by other processing threads executing in parallel;
instructions to initiate multiple accesses of data with respect to the globally accessible shared data for purposes of producing the transaction outcome during execution of the given processing thread; and
instructions to verify, at successive times during execution of the given processing thread, that a respective data value associated with a globally accessible version information variable does not change over time, the given processing thread aborting further execution if the globally accessible version information variable happens to change during a course of executing the given processing thread, the data value associated with the globally accessible version information variable being updated to a new value each time a respective one of the multiple processing threads modifies the globally accessible shared data.
16. A computer readable medium as in claim 15 , wherein instructions to verify include:
instructions to carry out each of multiple reads and verify whether the globally accessible version information variable remains set to a constant value from a first read to a next successive read associated with the given processing thread.
17. A computer readable medium as in claim 15 further including:
instructions to initiate a first read to retrieve respective data from the globally accessible shared data;
instructions to retrieve and store a respective data value associated with the globally accessible version information variable at a time associated with the first read;
instructions to initiate a second read to retrieve respective data from the globally accessible shared data at a later time with respect to the first read;
instructions to retrieve a respective data value associated with the globally accessible version information variable at a time associated with the second read; and
instructions to verify that the respective data value of the globally accessible version information variable for the first read is identical to the respective data value of the globally accessible version information variable for the next successive read.
18. A computer readable medium as in claim 17 further including:
instructions to abort further execution of the given processing thread if there is a corresponding lock on the globally accessible shared data, the corresponding lock indicating that another one of the multiple processing threads is in a process of modifying the globally accessible shared data.
19. A computer readable medium as in claim 15 further including:
instructions to initiate storage of at least one data value associated with the respective transaction outcome to the globally accessible shared data upon completion of the execution of the given processing thread;
instructions to check whether any of the other processing threads currently has a lock on the globally accessible shared data, presence of the lock indicating that another one of the multiple processing threads is in a process of modifying the globally accessible shared data prior to storage of the at least one data value to the globally accessible shared data; and
instructions to abort the given processing thread and store the at least one data value to the globally accessible shared data.
20. A computer readable medium method as in claim 15 further comprising:
instructions to check whether any one of the other processing threads currently has a lock on the globally accessible shared data;
instructions to abort and re-execute the given processing thread if there is a lock as indicated by a checking process;
instructions to initiate a respective commit phase with respect to the given processing thread if there is not a lock as indicated by a checking process, the commit phase including:
i) instructions to obtain a respective lock on the globally accessible shared data preventing the other processing threads from modifying the globally accessible shared data,
ii) instructions to initiate modification of the globally accessible shared data in accordance with the respective transaction outcome associated with the given processing thread,
iii) instructions to update a respective data value associated with the globally accessible version information variable to indicate to the other processing threads that the globally accessible shared data has been modified after the modification of globally accessible shared data, and
iv) instructions to release the respective lock on the globally accessible shared data at a same time as updating the respective data value associated with the globally accessible version information variable to a new value.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/475,604 US20070198978A1 (en) | 2006-02-22 | 2006-06-27 | Methods and apparatus to implement parallel transactions |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US77558006P | 2006-02-22 | 2006-02-22 | |
US77556406P | 2006-02-22 | 2006-02-22 | |
US78948306P | 2006-04-05 | 2006-04-05 | |
US11/475,604 US20070198978A1 (en) | 2006-02-22 | 2006-06-27 | Methods and apparatus to implement parallel transactions |
Publications (1)
Publication Number | Publication Date |
---|---|
US20070198978A1 true US20070198978A1 (en) | 2007-08-23 |
Family
ID=38429749
Family Applications (5)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/475,262 Active 2028-03-20 US8065499B2 (en) | 2006-02-22 | 2006-06-27 | Methods and apparatus to implement parallel transactions |
US11/475,604 Abandoned US20070198978A1 (en) | 2006-02-22 | 2006-06-27 | Methods and apparatus to implement parallel transactions |
US11/475,716 Abandoned US20070198979A1 (en) | 2006-02-22 | 2006-06-27 | Methods and apparatus to implement parallel transactions |
US11/475,814 Active 2028-01-05 US7669015B2 (en) | 2006-02-22 | 2006-06-27 | Methods and apparatus to implement parallel transactions |
US11/488,618 Active 2027-04-25 US7496716B2 (en) | 2006-02-22 | 2006-07-18 | Methods and apparatus to implement parallel transactions |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/475,262 Active 2028-03-20 US8065499B2 (en) | 2006-02-22 | 2006-06-27 | Methods and apparatus to implement parallel transactions |
Family Applications After (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/475,716 Abandoned US20070198979A1 (en) | 2006-02-22 | 2006-06-27 | Methods and apparatus to implement parallel transactions |
US11/475,814 Active 2028-01-05 US7669015B2 (en) | 2006-02-22 | 2006-06-27 | Methods and apparatus to implement parallel transactions |
US11/488,618 Active 2027-04-25 US7496716B2 (en) | 2006-02-22 | 2006-07-18 | Methods and apparatus to implement parallel transactions |
Country Status (1)
Country | Link |
---|---|
US (5) | US8065499B2 (en) |
Cited By (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080059808A1 (en) * | 2006-08-30 | 2008-03-06 | International Business Machines Corporation | Managing data access via a loop only if changed locking facility |
US20090006407A1 (en) * | 2007-06-27 | 2009-01-01 | Microsoft Corporation | Parallel nested transactions in transactional memory |
US20090019228A1 (en) * | 2007-07-12 | 2009-01-15 | Jeffrey Douglas Brown | Data Cache Invalidate with Data Dependent Expiration Using a Step Value |
US20090077083A1 (en) * | 2007-09-18 | 2009-03-19 | Microsoft Corporation | Parallel nested transactions in transactional memory |
US20090077082A1 (en) * | 2007-09-18 | 2009-03-19 | Microsoft Corporation, | Parallel nested transactions in transactional memory |
US20090172306A1 (en) * | 2007-12-31 | 2009-07-02 | Nussbaum Daniel S | System and Method for Supporting Phased Transactional Memory Modes |
US20090276563A1 (en) * | 2007-10-25 | 2009-11-05 | Leather Mark M | Incremental State Updates |
US20100017581A1 (en) * | 2008-07-18 | 2010-01-21 | Microsoft Corporation | Low overhead atomic memory operations |
US20100017434A1 (en) * | 2008-06-26 | 2010-01-21 | Lee Edward Lowry | Mechanisms to share attributes between objects |
US20100050161A1 (en) * | 2008-08-25 | 2010-02-25 | Yarden Nir-Buchbinder | Detecting Locking Discipline Violations on Shared Resources |
US20100211931A1 (en) * | 2009-02-13 | 2010-08-19 | Microsoft Corporation | Stm with global version overflow handling |
US20120117317A1 (en) * | 2009-08-20 | 2012-05-10 | Rambus Inc. | Atomic memory device |
US20120254139A1 (en) * | 2009-04-22 | 2012-10-04 | Microsoft Corporation | Providing lock-based access to nodes in a concurrent linked list |
US20140068127A1 (en) * | 2012-09-04 | 2014-03-06 | Red Hat Israel, Ltd. | Shared locking mechanism for storage centric leases |
US20150277967A1 (en) * | 2014-03-26 | 2015-10-01 | Irina Calciu | Enabling Maximum Concurrency In A Hybrid Transactional Memory System |
US9367505B2 (en) | 2013-12-20 | 2016-06-14 | International Business Machines Corporation | Coherency overcommit |
CN110162488A (en) * | 2018-11-15 | 2019-08-23 | 深圳乐信软件技术有限公司 | Buffer consistency method of calibration, device, server and storage medium |
US10931450B1 (en) * | 2018-04-27 | 2021-02-23 | Pure Storage, Inc. | Distributed, lock-free 2-phase commit of secret shares using multiple stateless controllers |
CN112596877A (en) * | 2020-12-18 | 2021-04-02 | 深圳Tcl新技术有限公司 | Global variable using method, device, system and computer readable storage medium |
Families Citing this family (187)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7362762B2 (en) * | 2003-11-12 | 2008-04-22 | Cisco Technology, Inc. | Distributed packet processing with ordered locks to maintain requisite packet orderings |
US7626987B2 (en) * | 2003-11-12 | 2009-12-01 | Cisco Technology, Inc. | Using ordered locking mechanisms to maintain sequences of items such as packets |
US7551617B2 (en) | 2005-02-08 | 2009-06-23 | Cisco Technology, Inc. | Multi-threaded packet processing architecture with global packet memory, packet recirculation, and coprocessor |
US7739426B1 (en) | 2005-10-31 | 2010-06-15 | Cisco Technology, Inc. | Descriptor transfer logic |
US7877565B1 (en) * | 2006-01-31 | 2011-01-25 | Nvidia Corporation | Constant versioning for multi-threaded processing |
US7797329B2 (en) * | 2006-06-09 | 2010-09-14 | Oracle America Inc. | Method and system for enabling a synchronization-free and parallel commit phase |
US20070299864A1 (en) * | 2006-06-24 | 2007-12-27 | Mark Strachan | Object storage subsystem computer program |
US7913236B2 (en) * | 2006-09-29 | 2011-03-22 | Intel Corporation | Method and apparatus for performing dynamic optimization for software transactional memory |
US7979858B2 (en) * | 2006-10-03 | 2011-07-12 | Sas Institute Inc. | Systems and methods for executing a computer program that executes multiple processes in a multi-processor environment |
US7610448B2 (en) * | 2006-12-27 | 2009-10-27 | Intel Corporation | Obscuring memory access patterns |
US8719807B2 (en) * | 2006-12-28 | 2014-05-06 | Intel Corporation | Handling precompiled binaries in a hardware accelerated software transactional memory system |
US20080229062A1 (en) * | 2007-03-12 | 2008-09-18 | Lorenzo Di Gregorio | Method of sharing registers in a processor and processor |
JP4444305B2 (en) * | 2007-03-28 | 2010-03-31 | 株式会社東芝 | Semiconductor device |
US7908255B2 (en) * | 2007-04-11 | 2011-03-15 | Microsoft Corporation | Transactional memory using buffered writes and enforced serialization order |
US7991956B2 (en) * | 2007-06-27 | 2011-08-02 | Intel Corporation | Providing application-level information for use in cache management |
US7890707B2 (en) * | 2007-06-27 | 2011-02-15 | Microsoft Corporation | Efficient retry for transactional memory |
US8140773B2 (en) * | 2007-06-27 | 2012-03-20 | Bratin Saha | Using ephemeral stores for fine-grained conflict detection in a hardware accelerated STM |
US9280397B2 (en) * | 2007-06-27 | 2016-03-08 | Intel Corporation | Using buffered stores or monitoring to filter redundant transactional accesses and mechanisms for mapping data to buffered metadata |
US7991967B2 (en) * | 2007-06-29 | 2011-08-02 | Microsoft Corporation | Using type stability to facilitate contention management |
US7698504B2 (en) * | 2007-07-03 | 2010-04-13 | Oracle America, Inc. | Cache line marking with shared timestamps |
US7890725B2 (en) * | 2007-07-09 | 2011-02-15 | International Business Machines Corporation | Bufferless transactional memory with runahead execution |
US7516365B2 (en) * | 2007-07-27 | 2009-04-07 | Sun Microsystems, Inc. | System and method for split hardware transactions |
US8375062B2 (en) * | 2007-11-19 | 2013-02-12 | Oracle America, Inc. | Simple optimistic skiplist |
US9513959B2 (en) * | 2007-11-21 | 2016-12-06 | Arm Limited | Contention management for a hardware transactional memory |
US8055879B2 (en) * | 2007-12-13 | 2011-11-08 | International Business Machines Corporation | Tracking network contention |
US8706982B2 (en) * | 2007-12-30 | 2014-04-22 | Intel Corporation | Mechanisms for strong atomicity in a transactional memory system |
US7904668B2 (en) * | 2007-12-31 | 2011-03-08 | Oracle America, Inc. | Optimistic semi-static transactional memory implementations |
US20090183159A1 (en) * | 2008-01-11 | 2009-07-16 | Michael Maged M | Managing concurrent transactions using bloom filters |
US20090187906A1 (en) * | 2008-01-23 | 2009-07-23 | Sun Microsystems, Inc. | Semi-ordered transactions |
CN104123239B (en) * | 2008-01-31 | 2017-07-21 | 甲骨文国际公司 | system and method for transactional cache |
GB2457341B (en) * | 2008-02-14 | 2010-07-21 | Transitive Ltd | Multiprocessor computing system with multi-mode memory consistency protection |
US9128750B1 (en) * | 2008-03-03 | 2015-09-08 | Parakinetics Inc. | System and method for supporting multi-threaded transactions |
US8200947B1 (en) * | 2008-03-24 | 2012-06-12 | Nvidia Corporation | Systems and methods for voting among parallel threads |
US9225545B2 (en) | 2008-04-01 | 2015-12-29 | International Business Machines Corporation | Determining a path for network traffic between nodes in a parallel computer |
US8930644B2 (en) * | 2008-05-02 | 2015-01-06 | Xilinx, Inc. | Configurable transactional memory for synchronizing transactions |
US9367363B2 (en) * | 2008-05-12 | 2016-06-14 | Oracle America, Inc. | System and method for integrating best effort hardware mechanisms for supporting transactional memory |
US8533663B2 (en) * | 2008-05-12 | 2013-09-10 | Oracle America, Inc. | System and method for utilizing available best effort hardware mechanisms for supporting transactional memory |
US8139488B2 (en) * | 2008-05-30 | 2012-03-20 | Cisco Technology, Inc. | Cooperative flow locks distributed among multiple components |
US9047139B2 (en) * | 2008-06-27 | 2015-06-02 | Microsoft Technology Licensing, Llc | Primitives for software transactional memory |
US8364481B2 (en) | 2008-07-02 | 2013-01-29 | Google Inc. | Speech recognition with parallel recognition tasks |
US20100057740A1 (en) * | 2008-08-26 | 2010-03-04 | Yang Ni | Accelerating a quiescence process of transactional memory |
US8001548B2 (en) * | 2008-10-20 | 2011-08-16 | Microsoft Corporation | Transaction processing for side-effecting actions in transactional memory |
US8166481B2 (en) * | 2008-10-20 | 2012-04-24 | Microsoft Corporation | Transaction processing in transactional memory |
US7941616B2 (en) * | 2008-10-21 | 2011-05-10 | Microsoft Corporation | System to reduce interference in concurrent programs |
US8789057B2 (en) * | 2008-12-03 | 2014-07-22 | Oracle America, Inc. | System and method for reducing serialization in transactional memory using gang release of blocked threads |
US9021502B2 (en) * | 2008-12-29 | 2015-04-28 | Oracle America Inc. | Method and system for inter-thread communication using processor messaging |
US8914620B2 (en) * | 2008-12-29 | 2014-12-16 | Oracle America, Inc. | Method and system for reducing abort rates in speculative lock elision using contention management mechanisms |
US8103838B2 (en) * | 2009-01-08 | 2012-01-24 | Oracle America, Inc. | System and method for transactional locking using reader-lists |
US8688921B2 (en) * | 2009-03-03 | 2014-04-01 | Microsoft Corporation | STM with multiple global version counters |
US20100228929A1 (en) * | 2009-03-09 | 2010-09-09 | Microsoft Corporation | Expedited completion of a transaction in stm |
US9418175B2 (en) * | 2009-03-31 | 2016-08-16 | Microsoft Technology Licensing, Llc | Enumeration of a concurrent data structure |
US20120110291A1 (en) * | 2009-04-06 | 2012-05-03 | Kaminario Technologies Ltd. | System and method for i/o command management |
US8413136B2 (en) | 2009-05-08 | 2013-04-02 | Microsoft Corporation | Application virtualization |
US8495103B2 (en) * | 2009-05-29 | 2013-07-23 | Red Hat, Inc. | Method and apparatus for determining how to transform applications into transactional applications |
US8429606B2 (en) | 2009-05-29 | 2013-04-23 | Red Hat, Inc. | Transactional object container |
US8356166B2 (en) * | 2009-06-26 | 2013-01-15 | Microsoft Corporation | Minimizing code duplication in an unbounded transactional memory system by using mode agnostic transactional read and write barriers |
US8489864B2 (en) * | 2009-06-26 | 2013-07-16 | Microsoft Corporation | Performing escape actions in transactions |
US8250331B2 (en) | 2009-06-26 | 2012-08-21 | Microsoft Corporation | Operating system virtual memory management for hardware transactional memory |
US8973004B2 (en) * | 2009-06-26 | 2015-03-03 | Oracle America, Inc. | Transactional locking with read-write locks in transactional memory systems |
KR101370314B1 (en) * | 2009-06-26 | 2014-03-05 | 인텔 코포레이션 | Optimizations for an unbounded transactional memory (utm) system |
US8302105B2 (en) * | 2009-06-26 | 2012-10-30 | Oracle America, Inc. | Bulk synchronization in transactional memory systems |
US8812796B2 (en) * | 2009-06-26 | 2014-08-19 | Microsoft Corporation | Private memory regions and coherence optimizations |
US8161247B2 (en) * | 2009-06-26 | 2012-04-17 | Microsoft Corporation | Wait loss synchronization |
US8370577B2 (en) | 2009-06-26 | 2013-02-05 | Microsoft Corporation | Metaphysically addressed cache metadata |
US8484438B2 (en) * | 2009-06-29 | 2013-07-09 | Oracle America, Inc. | Hierarchical bloom filters for facilitating concurrency control |
US8229907B2 (en) * | 2009-06-30 | 2012-07-24 | Microsoft Corporation | Hardware accelerated transactional memory system with open nested transactions |
US8542247B1 (en) | 2009-07-17 | 2013-09-24 | Nvidia Corporation | Cull before vertex attribute fetch and vertex lighting |
US8564616B1 (en) | 2009-07-17 | 2013-10-22 | Nvidia Corporation | Cull before vertex attribute fetch and vertex lighting |
JP4917138B2 (en) * | 2009-10-07 | 2012-04-18 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Object optimum arrangement device, object optimum arrangement method, and object optimum arrangement program |
US8976195B1 (en) | 2009-10-14 | 2015-03-10 | Nvidia Corporation | Generating clip state for a batch of vertices |
US8384736B1 (en) | 2009-10-14 | 2013-02-26 | Nvidia Corporation | Generating clip state for a batch of vertices |
US8595446B2 (en) * | 2009-11-25 | 2013-11-26 | Oracle America, Inc. | System and method for performing dynamic mixed mode read validation in a software transactional memory |
US9529839B2 (en) * | 2009-12-07 | 2016-12-27 | International Business Machines Corporation | Applying limited-size hardware transactional memory to arbitrarily large data structure |
US8375175B2 (en) * | 2009-12-09 | 2013-02-12 | Oracle America, Inc. | Fast and efficient reacquisition of locks for transactional memory systems |
US9092253B2 (en) * | 2009-12-15 | 2015-07-28 | Microsoft Technology Licensing, Llc | Instrumentation of hardware assisted transactional memory system |
US8402218B2 (en) | 2009-12-15 | 2013-03-19 | Microsoft Corporation | Efficient garbage collection and exception handling in a hardware accelerated transactional memory system |
US8533440B2 (en) * | 2009-12-15 | 2013-09-10 | Microsoft Corporation | Accelerating parallel transactions using cache resident transactions |
US8539465B2 (en) | 2009-12-15 | 2013-09-17 | Microsoft Corporation | Accelerating unbounded memory transactions using nested cache resident transactions |
US8396831B2 (en) * | 2009-12-18 | 2013-03-12 | Microsoft Corporation | Optimistic serializable snapshot isolation |
US8356007B2 (en) | 2010-10-20 | 2013-01-15 | Microsoft Corporation | Distributed transaction management for database systems with multiversioning |
US8645650B2 (en) * | 2010-01-29 | 2014-02-04 | Red Hat, Inc. | Augmented advisory lock mechanism for tightly-coupled clusters |
US8943502B2 (en) * | 2010-03-15 | 2015-01-27 | International Business Machines Corporation | Retooling lock interfaces for using a dual mode reader writer lock |
US8402227B2 (en) * | 2010-03-31 | 2013-03-19 | Oracle International Corporation | System and method for committing results of a software transaction using a hardware transaction |
US9467338B2 (en) * | 2010-04-01 | 2016-10-11 | Blackberry Limited | Method for communicating device management data changes |
US9251214B2 (en) * | 2010-04-08 | 2016-02-02 | Microsoft Technology Licensing, Llc | In-memory database system |
US9652440B2 (en) | 2010-05-27 | 2017-05-16 | Microsoft Technology Licensing, Llc | Concurrent utilization of a document by multiple threads |
US8555161B2 (en) | 2010-05-27 | 2013-10-08 | Microsoft Corporation | Concurrent editing of a document by multiple clients |
US9965387B1 (en) * | 2010-07-09 | 2018-05-08 | Cypress Semiconductor Corporation | Memory devices having embedded hardware acceleration and corresponding methods |
US8510304B1 (en) | 2010-08-27 | 2013-08-13 | Amazon Technologies, Inc. | Transactionally consistent indexing for data blobs |
US8510344B1 (en) | 2010-08-27 | 2013-08-13 | Amazon Technologies, Inc. | Optimistically consistent arbitrary data blob transactions |
US8856089B1 (en) * | 2010-08-27 | 2014-10-07 | Amazon Technologies, Inc. | Sub-containment concurrency for hierarchical data containers |
US8402061B1 (en) | 2010-08-27 | 2013-03-19 | Amazon Technologies, Inc. | Tiered middleware framework for data storage |
US8688666B1 (en) | 2010-08-27 | 2014-04-01 | Amazon Technologies, Inc. | Multi-blob consistency for atomic data transactions |
US8782147B2 (en) * | 2010-09-09 | 2014-07-15 | Red Hat, Inc. | Concurrent delivery for messages from a same sender |
US8412691B2 (en) | 2010-09-10 | 2013-04-02 | International Business Machines Corporation | Maintenance and access of a linked list |
US8621161B1 (en) | 2010-09-23 | 2013-12-31 | Amazon Technologies, Inc. | Moving data between data stores |
US8949453B2 (en) | 2010-11-30 | 2015-02-03 | International Business Machines Corporation | Data communications in a parallel active messaging interface of a parallel computer |
US8788474B2 (en) * | 2010-12-17 | 2014-07-22 | Red Hat, Inc. | Inode event notification for cluster file systems |
WO2012117389A1 (en) * | 2011-02-28 | 2012-09-07 | Dsp Group Ltd. | A method and an apparatus for coherency control |
US9542164B1 (en) * | 2011-03-02 | 2017-01-10 | The Mathworks, Inc. | Managing an application variable using variable attributes |
US8898390B2 (en) | 2011-03-08 | 2014-11-25 | Intel Corporation | Scheduling workloads based on cache asymmetry |
JP5218585B2 (en) * | 2011-03-15 | 2013-06-26 | オムロン株式会社 | Control device and system program |
US9069893B2 (en) * | 2011-03-23 | 2015-06-30 | International Business Machines Corporation | Automatic verification of determinism for parallel programs |
US8484235B2 (en) | 2011-03-28 | 2013-07-09 | International Business Machines Corporation | Dynamically switching the serialization method of a data structure |
US9043363B2 (en) * | 2011-06-03 | 2015-05-26 | Oracle International Corporation | System and method for performing memory management using hardware transactions |
US8924930B2 (en) | 2011-06-28 | 2014-12-30 | Microsoft Corporation | Virtual machine image lineage |
US8949328B2 (en) | 2011-07-13 | 2015-02-03 | International Business Machines Corporation | Performing collective operations in a distributed processing system |
US10048990B2 (en) * | 2011-11-19 | 2018-08-14 | International Business Machines Corporation | Parallel access of partially locked content of input file |
BR112014014414A2 (en) * | 2011-12-14 | 2017-06-13 | Optis Cellular Tech Llc | Temporary storage resource management method and telecommunication equipment |
JP5861445B2 (en) * | 2011-12-21 | 2016-02-16 | 富士ゼロックス株式会社 | Information processing apparatus and information processing program |
US8930962B2 (en) | 2012-02-22 | 2015-01-06 | International Business Machines Corporation | Processing unexpected messages at a compute node of a parallel computer |
WO2013175858A1 (en) * | 2012-05-23 | 2013-11-28 | 日本電気株式会社 | Lock management system, lock management method, and lock management program |
WO2013179451A1 (en) * | 2012-05-31 | 2013-12-05 | 国立大学法人東京大学 | Parallel data processing system, computer, and parallel data processing method |
US8688661B2 (en) | 2012-06-15 | 2014-04-01 | International Business Machines Corporation | Transactional processing |
US8966324B2 (en) | 2012-06-15 | 2015-02-24 | International Business Machines Corporation | Transactional execution branch indications |
US10437602B2 (en) | 2012-06-15 | 2019-10-08 | International Business Machines Corporation | Program interruption filtering in transactional execution |
US20130339680A1 (en) * | 2012-06-15 | 2013-12-19 | International Business Machines Corporation | Nontransactional store instruction |
US9448796B2 (en) | 2012-06-15 | 2016-09-20 | International Business Machines Corporation | Restricted instructions in transactional execution |
US9336046B2 (en) | 2012-06-15 | 2016-05-10 | International Business Machines Corporation | Transaction abort processing |
US9367323B2 (en) | 2012-06-15 | 2016-06-14 | International Business Machines Corporation | Processor assist facility |
US8880959B2 (en) | 2012-06-15 | 2014-11-04 | International Business Machines Corporation | Transaction diagnostic block |
US9772854B2 (en) | 2012-06-15 | 2017-09-26 | International Business Machines Corporation | Selectively controlling instruction execution in transactional processing |
US8682877B2 (en) | 2012-06-15 | 2014-03-25 | International Business Machines Corporation | Constrained transaction execution |
US9317460B2 (en) | 2012-06-15 | 2016-04-19 | International Business Machines Corporation | Program event recording within a transactional environment |
US9384004B2 (en) | 2012-06-15 | 2016-07-05 | International Business Machines Corporation | Randomized testing within transactional execution |
US9436477B2 (en) | 2012-06-15 | 2016-09-06 | International Business Machines Corporation | Transaction abort instruction |
US9740549B2 (en) | 2012-06-15 | 2017-08-22 | International Business Machines Corporation | Facilitating transaction completion subsequent to repeated aborts of the transaction |
US9348642B2 (en) | 2012-06-15 | 2016-05-24 | International Business Machines Corporation | Transaction begin/end instructions |
US9361115B2 (en) | 2012-06-15 | 2016-06-07 | International Business Machines Corporation | Saving/restoring selected registers in transactional processing |
US9442737B2 (en) | 2012-06-15 | 2016-09-13 | International Business Machines Corporation | Restricting processing within a processor to facilitate transaction completion |
US9298632B2 (en) * | 2012-06-28 | 2016-03-29 | Intel Corporation | Hybrid cache state and filter tracking of memory operations during a transaction |
US8862561B1 (en) * | 2012-08-30 | 2014-10-14 | Google Inc. | Detecting read/write conflicts |
CN103049334B (en) * | 2012-12-14 | 2015-09-30 | 华为技术有限公司 | A kind of method of task process and virtual machine |
US9547594B2 (en) | 2013-03-15 | 2017-01-17 | Intel Corporation | Instructions to mark beginning and end of non transactional code region requiring write back to persistent storage |
US20140289739A1 (en) * | 2013-03-20 | 2014-09-25 | Hewlett-Packard Development Company, L.P. | Allocating and sharing a data object among program instances |
US9384257B2 (en) | 2013-06-24 | 2016-07-05 | International Business Machines Corporation | Providing multiple concurrent transactions on a single database schema using a single concurrent transaction database infrastructure |
US20150074219A1 (en) * | 2013-07-12 | 2015-03-12 | Brocade Communications Systems, Inc. | High availability networking using transactional memory |
WO2015009275A1 (en) * | 2013-07-15 | 2015-01-22 | Intel Corporation | Improved transactional memory management techniques |
US9817771B2 (en) | 2013-08-20 | 2017-11-14 | Synopsys, Inc. | Guarded memory access in a multi-thread safe system level modeling simulation |
US9588801B2 (en) | 2013-09-11 | 2017-03-07 | Intel Corporation | Apparatus and method for improved lock elision techniques |
US9292444B2 (en) | 2013-09-26 | 2016-03-22 | International Business Machines Corporation | Multi-granular cache management in multi-processor computing environments |
US9298623B2 (en) | 2013-09-26 | 2016-03-29 | Globalfoundries Inc. | Identifying high-conflict cache lines in transactional memory computing environments |
US9086974B2 (en) | 2013-09-26 | 2015-07-21 | International Business Machines Corporation | Centralized management of high-contention cache lines in multi-processor computing environments |
US9329890B2 (en) | 2013-09-26 | 2016-05-03 | Globalfoundries Inc. | Managing high-coherence-miss cache lines in multi-processor computing environments |
US9298626B2 (en) | 2013-09-26 | 2016-03-29 | Globalfoundries Inc. | Managing high-conflict cache lines in transactional memory computing environments |
US10013351B2 (en) | 2014-06-27 | 2018-07-03 | International Business Machines Corporation | Transactional execution processor having a co-processor accelerator, both sharing a higher level cache |
US9477481B2 (en) | 2014-06-27 | 2016-10-25 | International Business Machines Corporation | Accurate tracking of transactional read and write sets with speculation |
US9772944B2 (en) | 2014-06-27 | 2017-09-26 | International Business Machines Corporation | Transactional execution in a multi-processor environment that monitors memory conflicts in a shared cache |
US9703718B2 (en) | 2014-06-27 | 2017-07-11 | International Business Machines Corporation | Managing read tags in a transactional memory |
US9740614B2 (en) | 2014-06-27 | 2017-08-22 | International Business Machines Corporation | Processor directly storing address range of co-processor memory accesses in a transactional memory where co-processor supplements functions of the processor |
US9658961B2 (en) | 2014-06-27 | 2017-05-23 | International Business Machines Corporation | Speculation control for improving transaction success rate, and instruction therefor |
US10114752B2 (en) | 2014-06-27 | 2018-10-30 | International Business Machines Corporation | Detecting cache conflicts by utilizing logical address comparisons in a transactional memory |
US9720837B2 (en) | 2014-06-27 | 2017-08-01 | International Business Machines Corporation | Allowing non-cacheable loads within a transaction |
US10025715B2 (en) | 2014-06-27 | 2018-07-17 | International Business Machines Corporation | Conditional inclusion of data in a transactional memory read set |
US10073784B2 (en) | 2014-06-27 | 2018-09-11 | International Business Machines Corporation | Memory performance when speculation control is enabled, and instruction therefor |
US9600327B2 (en) * | 2014-07-10 | 2017-03-21 | Oracle International Corporation | Process scheduling and execution in distributed computing environments |
US10489213B2 (en) * | 2014-10-01 | 2019-11-26 | Red Hat, Inc. | Execution of a method at a cluster of nodes |
GB2533415B (en) * | 2014-12-19 | 2022-01-19 | Advanced Risc Mach Ltd | Apparatus with at least one resource having thread mode and transaction mode, and method |
CN107466399B (en) * | 2015-05-01 | 2020-12-04 | 慧与发展有限责任合伙企业 | System and method for providing throttled data memory access |
US10067960B2 (en) | 2015-06-04 | 2018-09-04 | Microsoft Technology Licensing, Llc | Controlling atomic updates of indexes using hardware transactional memory |
US9858189B2 (en) * | 2015-06-24 | 2018-01-02 | International Business Machines Corporation | Hybrid tracking of transaction read and write sets |
US9760494B2 (en) | 2015-06-24 | 2017-09-12 | International Business Machines Corporation | Hybrid tracking of transaction read and write sets |
US20170017419A1 (en) | 2015-07-15 | 2017-01-19 | Innovium, Inc. | System And Method For Enabling High Read Rates To Data Element Lists |
US20170017567A1 (en) | 2015-07-15 | 2017-01-19 | Innovium, Inc. | System And Method For Implementing Distributed-Linked Lists For Network Devices |
US20170017414A1 (en) | 2015-07-15 | 2017-01-19 | Innovium, Inc. | System And Method For Implementing Hierarchical Distributed-Linked Lists For Network Devices |
US20170017420A1 (en) | 2015-07-15 | 2017-01-19 | Innovium, Inc. | System And Method For Enabling High Read Rates To Data Element Lists |
US10095641B2 (en) | 2015-09-23 | 2018-10-09 | Hanan Potash | Processor with frames/bins structure in local high speed memory |
US9977693B2 (en) | 2015-09-23 | 2018-05-22 | Hanan Potash | Processor that uses plural form information |
US10067878B2 (en) | 2015-09-23 | 2018-09-04 | Hanan Potash | Processor with logical mentor |
US10140122B2 (en) | 2015-09-23 | 2018-11-27 | Hanan Potash | Computer processor with operand/variable-mapped namespace |
WO2017053828A1 (en) * | 2015-09-23 | 2017-03-30 | Hanan Potash | Computing device with frames/bins structure, mentor layer and plural operand processing |
US10061511B2 (en) * | 2015-09-23 | 2018-08-28 | Hanan Potash | Computing device with frames/bins structure, mentor layer and plural operand processing |
US9811392B2 (en) * | 2015-11-24 | 2017-11-07 | Microsoft Technology Licensing, Llc | Precondition exclusivity mapping of tasks to computational locations |
US10140021B2 (en) * | 2015-12-23 | 2018-11-27 | Netapp, Inc. | Adaptive data-partitioning model that responds to observed workload |
US11093286B2 (en) | 2016-04-26 | 2021-08-17 | Hanan Potash | Computing device with resource manager and civilware tier |
US10733091B2 (en) | 2016-05-03 | 2020-08-04 | International Business Machines Corporation | Read and write sets for ranges of instructions of transactions |
US10042761B2 (en) * | 2016-05-03 | 2018-08-07 | International Business Machines Corporation | Read and write sets for transactions of a multithreaded computing environment |
US11120002B2 (en) * | 2016-07-20 | 2021-09-14 | Verizon Media Inc. | Method and system for concurrent database operation |
US10467198B2 (en) * | 2016-09-15 | 2019-11-05 | Oracle International Corporation | Network partition tolerance in a high available centralized VCS implementation |
US10528479B2 (en) * | 2017-06-02 | 2020-01-07 | Huawei Technologies Co., Ltd. | Global variable migration via virtual memory overlay technique for multi-version asynchronous dynamic software update |
US10430187B2 (en) * | 2017-08-15 | 2019-10-01 | Oracle International Corporation | Persistent transactional memory metadata-based buffer caches |
CN107844385B (en) * | 2017-11-08 | 2021-04-23 | 北京龙之心科技有限公司 | Variable read-write method and device based on shared memory |
US10698802B1 (en) * | 2018-03-21 | 2020-06-30 | Cadence Design Systems, Inc. | Method and system for generating a validation test |
US11409559B2 (en) * | 2019-10-24 | 2022-08-09 | EMC IP Holding Company, LLC | System and method for weak lock allowing force preemption by high priority thread |
US11086779B2 (en) * | 2019-11-11 | 2021-08-10 | Vmware, Inc. | System and method of a highly concurrent cache replacement algorithm |
CN111831557B (en) * | 2020-06-19 | 2023-10-20 | 北京华三通信技术有限公司 | Deadlock detection method and device |
US11593275B2 (en) | 2021-06-01 | 2023-02-28 | International Business Machines Corporation | Operating system deactivation of storage block write protection absent quiescing of processors |
Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5649200A (en) * | 1993-01-08 | 1997-07-15 | Atria Software, Inc. | Dynamic rule-based version control system |
US5950199A (en) * | 1997-07-11 | 1999-09-07 | International Business Machines Corporation | Parallel file system and method for granting byte range tokens |
US6101590A (en) * | 1995-10-10 | 2000-08-08 | Micro Unity Systems Engineering, Inc. | Virtual memory system with local and global virtual address translation |
US6393437B1 (en) * | 1998-01-27 | 2002-05-21 | Microsoft Corporation | Web developer isolation techniques |
US6757893B1 (en) * | 1999-12-17 | 2004-06-29 | Canon Kabushiki Kaisha | Version control system for software code |
US6810470B1 (en) * | 2000-08-14 | 2004-10-26 | Ati Technologies, Inc. | Memory request interlock |
US20060106996A1 (en) * | 2004-11-15 | 2006-05-18 | Ahmad Said A | Updating data shared among systems |
US20060161919A1 (en) * | 2004-12-23 | 2006-07-20 | Onufryk Peter Z | Implementation of load linked and store conditional operations |
US20060236039A1 (en) * | 2005-04-19 | 2006-10-19 | International Business Machines Corporation | Method and apparatus for synchronizing shared data between components in a group |
US7313794B1 (en) * | 2003-01-30 | 2007-12-25 | Xilinx, Inc. | Method and apparatus for synchronization of shared memory in a multiprocessor system |
US7467378B1 (en) * | 2004-02-09 | 2008-12-16 | Symantec Corporation | System state rollback after modification failure |
US7536517B2 (en) * | 2005-07-29 | 2009-05-19 | Microsoft Corporation | Direct-update software transactional memory |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5301290A (en) * | 1990-03-14 | 1994-04-05 | International Business Machines Corporation | Method for minimizing lock processing while ensuring consistency among pages common to local processor caches and a shared external store |
US5596754A (en) * | 1992-10-29 | 1997-01-21 | Digital Equipment Corporation | Method for performing private lock management |
US6148377A (en) * | 1996-11-22 | 2000-11-14 | Mangosoft Corporation | Shared memory computer networks |
US5987506A (en) * | 1996-11-22 | 1999-11-16 | Mangosoft Corporation | Remote access and geographically distributed computers in a globally addressable storage environment |
US5956731A (en) * | 1997-04-23 | 1999-09-21 | Oracle Corporation | Sharing snapshots for consistent reads |
JP3874996B2 (en) * | 2000-05-30 | 2007-01-31 | ファブソリューション株式会社 | Device inspection method and apparatus |
US6826570B1 (en) * | 2000-07-18 | 2004-11-30 | International Business Machines Corporation | Dynamically switching between different types of concurrency control techniques to provide an adaptive access strategy for a parallel file system |
US6678772B2 (en) | 2000-12-19 | 2004-01-13 | International Businesss Machines Corporation | Adaptive reader-writer lock |
US20050038961A1 (en) * | 2003-08-11 | 2005-02-17 | Chao-Wu Chen | Cache and memory architecture for fast program space access |
US7395263B2 (en) * | 2005-10-12 | 2008-07-01 | International Business Machines Corporation | Realtime-safe read copy update with lock-free readers |
US20070124546A1 (en) | 2005-11-29 | 2007-05-31 | Anton Blanchard | Automatic yielding on lock contention for a multi-threaded processor |
-
2006
- 2006-06-27 US US11/475,262 patent/US8065499B2/en active Active
- 2006-06-27 US US11/475,604 patent/US20070198978A1/en not_active Abandoned
- 2006-06-27 US US11/475,716 patent/US20070198979A1/en not_active Abandoned
- 2006-06-27 US US11/475,814 patent/US7669015B2/en active Active
- 2006-07-18 US US11/488,618 patent/US7496716B2/en active Active
Patent Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5649200A (en) * | 1993-01-08 | 1997-07-15 | Atria Software, Inc. | Dynamic rule-based version control system |
US6101590A (en) * | 1995-10-10 | 2000-08-08 | Micro Unity Systems Engineering, Inc. | Virtual memory system with local and global virtual address translation |
US5950199A (en) * | 1997-07-11 | 1999-09-07 | International Business Machines Corporation | Parallel file system and method for granting byte range tokens |
US6393437B1 (en) * | 1998-01-27 | 2002-05-21 | Microsoft Corporation | Web developer isolation techniques |
US6757893B1 (en) * | 1999-12-17 | 2004-06-29 | Canon Kabushiki Kaisha | Version control system for software code |
US6810470B1 (en) * | 2000-08-14 | 2004-10-26 | Ati Technologies, Inc. | Memory request interlock |
US7313794B1 (en) * | 2003-01-30 | 2007-12-25 | Xilinx, Inc. | Method and apparatus for synchronization of shared memory in a multiprocessor system |
US7467378B1 (en) * | 2004-02-09 | 2008-12-16 | Symantec Corporation | System state rollback after modification failure |
US20060106996A1 (en) * | 2004-11-15 | 2006-05-18 | Ahmad Said A | Updating data shared among systems |
US20060161919A1 (en) * | 2004-12-23 | 2006-07-20 | Onufryk Peter Z | Implementation of load linked and store conditional operations |
US20060236039A1 (en) * | 2005-04-19 | 2006-10-19 | International Business Machines Corporation | Method and apparatus for synchronizing shared data between components in a group |
US7536517B2 (en) * | 2005-07-29 | 2009-05-19 | Microsoft Corporation | Direct-update software transactional memory |
Non-Patent Citations (1)
Title |
---|
Anderson et al., "Real-time computing with lock-free shared objects", ACM Transactions on Computer Systems (TOCS) 15.2, 1997, pp. 134-165. * |
Cited By (47)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7861093B2 (en) * | 2006-08-30 | 2010-12-28 | International Business Machines Corporation | Managing data access via a loop only if changed locking facility |
US20080059808A1 (en) * | 2006-08-30 | 2008-03-06 | International Business Machines Corporation | Managing data access via a loop only if changed locking facility |
US20090006407A1 (en) * | 2007-06-27 | 2009-01-01 | Microsoft Corporation | Parallel nested transactions in transactional memory |
US7962456B2 (en) | 2007-06-27 | 2011-06-14 | Microsoft Corporation | Parallel nested transactions in transactional memory |
US20090019228A1 (en) * | 2007-07-12 | 2009-01-15 | Jeffrey Douglas Brown | Data Cache Invalidate with Data Dependent Expiration Using a Step Value |
US7996621B2 (en) * | 2007-07-12 | 2011-08-09 | International Business Machines Corporation | Data cache invalidate with data dependent expiration using a step value |
US9411635B2 (en) | 2007-09-18 | 2016-08-09 | Microsoft Technology Licensing, Llc | Parallel nested transactions in transactional memory |
US20110040738A1 (en) * | 2007-09-18 | 2011-02-17 | Microsoft Corporation | Parallel nested transactions in transactional memory |
US20090077082A1 (en) * | 2007-09-18 | 2009-03-19 | Microsoft Corporation, | Parallel nested transactions in transactional memory |
US20090077083A1 (en) * | 2007-09-18 | 2009-03-19 | Microsoft Corporation | Parallel nested transactions in transactional memory |
WO2009039120A2 (en) * | 2007-09-18 | 2009-03-26 | Microsoft Corporation | Parallel nested transactions in transactional memory |
US8271464B2 (en) | 2007-09-18 | 2012-09-18 | Microsoft Corporation | Parallel nested transactions in transactional memory |
US8271465B2 (en) | 2007-09-18 | 2012-09-18 | Microsoft Corporation | Parallel nested transactions in transactional memory |
US7840530B2 (en) | 2007-09-18 | 2010-11-23 | Microsoft Corporation | Parallel nested transactions in transactional memory |
WO2009039120A3 (en) * | 2007-09-18 | 2009-05-28 | Microsoft Corp | Parallel nested transactions in transactional memory |
US7890472B2 (en) | 2007-09-18 | 2011-02-15 | Microsoft Corporation | Parallel nested transactions in transactional memory |
US20110138145A1 (en) * | 2007-09-18 | 2011-06-09 | Microsoft Corporation | Parallel nested transactions in transactional memory |
US8156314B2 (en) * | 2007-10-25 | 2012-04-10 | Advanced Micro Devices, Inc. | Incremental state updates |
US20090276563A1 (en) * | 2007-10-25 | 2009-11-05 | Leather Mark M | Incremental State Updates |
US20090172306A1 (en) * | 2007-12-31 | 2009-07-02 | Nussbaum Daniel S | System and Method for Supporting Phased Transactional Memory Modes |
US8589358B2 (en) * | 2008-06-26 | 2013-11-19 | Emc Corporation | Mechanisms to share attributes between objects |
US20100017434A1 (en) * | 2008-06-26 | 2010-01-21 | Lee Edward Lowry | Mechanisms to share attributes between objects |
US20100017581A1 (en) * | 2008-07-18 | 2010-01-21 | Microsoft Corporation | Low overhead atomic memory operations |
US8479166B2 (en) * | 2008-08-25 | 2013-07-02 | International Business Machines Corporation | Detecting locking discipline violations on shared resources |
US20130239094A1 (en) * | 2008-08-25 | 2013-09-12 | International Business Machines Corporation | Detecting locking discipline violations on shared resources |
US20100050161A1 (en) * | 2008-08-25 | 2010-02-25 | Yarden Nir-Buchbinder | Detecting Locking Discipline Violations on Shared Resources |
US20100211931A1 (en) * | 2009-02-13 | 2010-08-19 | Microsoft Corporation | Stm with global version overflow handling |
US8627292B2 (en) * | 2009-02-13 | 2014-01-07 | Microsoft Corporation | STM with global version overflow handling |
US20120254139A1 (en) * | 2009-04-22 | 2012-10-04 | Microsoft Corporation | Providing lock-based access to nodes in a concurrent linked list |
US9519524B2 (en) * | 2009-04-22 | 2016-12-13 | Microsoft Technology Licensing, Llc | Providing lock-based access to nodes in a concurrent linked list |
US9658953B2 (en) | 2009-08-20 | 2017-05-23 | Rambus Inc. | Single command, multiple column-operation memory device |
US10552310B2 (en) | 2009-08-20 | 2020-02-04 | Rambus Inc. | Single command, multiple column-operation memory device |
US20120117317A1 (en) * | 2009-08-20 | 2012-05-10 | Rambus Inc. | Atomic memory device |
US11748252B2 (en) | 2009-08-20 | 2023-09-05 | Rambus Inc. | Data write from pre-programmed register |
US9898400B2 (en) | 2009-08-20 | 2018-02-20 | Rambus Inc. | Single command, multiple column-operation memory device |
US11720485B2 (en) | 2009-08-20 | 2023-08-08 | Rambus Inc. | DRAM with command-differentiated storage of internally and externally sourced data |
US11204863B2 (en) | 2009-08-20 | 2021-12-21 | Rambus Inc. | Memory component that performs data write from pre-programmed register |
US9542237B2 (en) * | 2012-09-04 | 2017-01-10 | Red Hat Israel, Ltd. | Shared locking for storage centric exclusive locks |
US20140068127A1 (en) * | 2012-09-04 | 2014-03-06 | Red Hat Israel, Ltd. | Shared locking mechanism for storage centric leases |
US9367504B2 (en) | 2013-12-20 | 2016-06-14 | International Business Machines Corporation | Coherency overcommit |
US9367505B2 (en) | 2013-12-20 | 2016-06-14 | International Business Machines Corporation | Coherency overcommit |
US9971627B2 (en) * | 2014-03-26 | 2018-05-15 | Intel Corporation | Enabling maximum concurrency in a hybrid transactional memory system |
KR101834262B1 (en) | 2014-03-26 | 2018-04-13 | 인텔 코포레이션 | Enabling maximum concurrency in a hybrid transactional memory system |
US20150277967A1 (en) * | 2014-03-26 | 2015-10-01 | Irina Calciu | Enabling Maximum Concurrency In A Hybrid Transactional Memory System |
US10931450B1 (en) * | 2018-04-27 | 2021-02-23 | Pure Storage, Inc. | Distributed, lock-free 2-phase commit of secret shares using multiple stateless controllers |
CN110162488A (en) * | 2018-11-15 | 2019-08-23 | 深圳乐信软件技术有限公司 | Buffer consistency method of calibration, device, server and storage medium |
CN112596877A (en) * | 2020-12-18 | 2021-04-02 | 深圳Tcl新技术有限公司 | Global variable using method, device, system and computer readable storage medium |
Also Published As
Publication number | Publication date |
---|---|
US20070198519A1 (en) | 2007-08-23 |
US20070198781A1 (en) | 2007-08-23 |
US7496716B2 (en) | 2009-02-24 |
US20070198979A1 (en) | 2007-08-23 |
US7669015B2 (en) | 2010-02-23 |
US8065499B2 (en) | 2011-11-22 |
US20070198792A1 (en) | 2007-08-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8065499B2 (en) | Methods and apparatus to implement parallel transactions | |
US8028133B2 (en) | Globally incremented variable or clock based methods and apparatus to implement parallel transactions | |
US8255626B2 (en) | Atomic commit predicated on consistency of watches | |
JP5054665B2 (en) | Comparison and exchange operation using sleep-wake mechanism | |
US8190859B2 (en) | Critical section detection and prediction mechanism for hardware lock elision | |
US8627048B2 (en) | Mechanism for irrevocable transactions | |
US8200909B2 (en) | Hardware acceleration of a write-buffering software transactional memory | |
JP5416223B2 (en) | Memory model of hardware attributes in a transactional memory system | |
KR101617975B1 (en) | Method, apparatus, and system for adaptive thread scheduling in transactional memory systems | |
US7958319B2 (en) | Hardware acceleration for a software transactional memory system | |
US9052947B2 (en) | Unified optimistic and pessimistic concurrency control for a software transactional memory (STM) system | |
US8468526B2 (en) | Concurrent thread execution using user-level asynchronous signaling | |
RU2501071C2 (en) | Late lock acquire mechanism for hardware lock elision (hle) | |
US8180986B2 (en) | Memory conflict detection via mapping of the physical heap to control access permissions to the memory |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: SUN MICROSYSTEMS, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DICE, DAVID;SHAVIT, NIR N.;REEL/FRAME:018017/0711;SIGNING DATES FROM 20060620 TO 20060621 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |