Abstract: A first data accessor acquires a lock associated with a critical section. The first data accessor initiates a help session associated with a first operation of the critical section. In the help session, a second data accessor (which has not acquired the first lock) performs one or more sub-operations of the first operation. The first data accessor releases the lock after at least the first operation has been completed.

Abstract: Transactional Lock Elision allows hardware transactions to execute unmodified critical sections protected by the same lock concurrently, by subscribing to the lock and verifying that it is available before committing the transaction. A “lazy subscription” optimization, which delays lock subscription, can potentially cause behavior that cannot occur when the critical sections are executed under the lock. Hardware extensions may provide mechanisms to ensure that lazy subscriptions are safe (e.g., that they result in correct behavior). Prior to executing a critical section transactionally, its lock and subscription code may be identified (e.g., by writing their locations to special registers). Prior to committing the transaction, the thread executing the critical section may verify that the correct lock was correctly subscribed to. If not, or if locations identified by the special registers have been modified, the transaction may be aborted.

Abstract: A first data accessor acquires a lock associated with a critical section. The first data accessor initiates a help session associated with a first operation of the critical section. In the help session, a second data accessor (which has not acquired the first lock) performs one or more sub-operations of the first operation. The first data accessor releases the lock after at least the first operation has been completed.

Abstract: Transactional Lock Elision allows hardware transactions to execute unmodified critical sections protected by the same lock concurrently, by subscribing to the lock and verifying that it is available before committing the transaction. A “lazy subscription” optimization, which delays lock subscription, can potentially cause behavior that cannot occur when the critical sections are executed under the lock. Hardware extensions may provide mechanisms to ensure that lazy subscriptions are safe (e.g., that they result in correct behavior). Prior to executing a critical section transactionally, its lock and subscription code may be identified (e.g., by writing their locations to special registers). Prior to committing the transaction, the thread executing the critical section may verify that the correct lock was correctly subscribed to. If not, or if locations identified by the special registers have been modified, the transaction may be aborted.

Abstract: A remove operation and an add-to-front operation may be currently performed with respect to nodes in an Least Recently Used (LRU) queue. A remove operation for a node may proceed if a lock can be obtained on the node to be removed and a predecessor node. During the remove operation, an add-to-front operation may proceed if a lock can be obtained on a dummy node that precedes the current front node of the LRU queue.

Abstract: A first data accessor acquires a lock associated with a critical section. The first data accessor initiates a help session associated with a first operation of the critical section. In the help session, a second data accessor (which has not acquired the first lock) performs one or more sub-operations of the first operation. The first data accessor releases the lock after at least the first operation has been completed.

Abstract: An HTM-assisted Combining Framework (HCF) may enable multiple (combiner and non-combiner) threads to access a shared data structure concurrently using hardware transactional memory (HTM). As long as a combiner executes in a hardware transaction and ensures that the lock associated with the data structure is available, it may execute concurrently with other threads operating on the data structure. HCF may include attempting to apply operations to a concurrent data structure utilizing HTM and if the HTM attempt fails, utilizing flat combining within HTM transactions. Publication lists may be used to announce operations to be applied to a concurrent data structure. A combiner thread may select a subset of the operations in the publication list and attempt to apply the selected operations using HTM. If the thread fails in these HTM attempts, it may acquire a lock associated with the data structure and apply the selected operations without HTM.

Abstract: A first data accessor acquires a lock associated with a critical section. The first data accessor initiates a help session associated with a first operation of the critical section. In the help session, a second data accessor (which has not acquired the first lock) performs one or more sub-operations of the first operation. The first data accessor releases the lock after at least the first operation has been completed.

Abstract: Transactional Lock Elision allows hardware transactions to execute unmodified critical sections protected by the same lock concurrently, by subscribing to the lock and verifying that it is available before committing the transaction. A “lazy subscription” optimization, which delays lock subscription, can potentially cause behavior that cannot occur when the critical sections are executed under the lock. Hardware extensions may provide mechanisms to ensure that lazy subscriptions are safe (e.g., that they result in correct behavior). Prior to executing a critical section transactionally, its lock and subscription code may be identified (e.g., by writing their locations to special registers). Prior to committing the transaction, the thread executing the critical section may verify that the correct lock was correctly subscribed to. If not, or if locations identified by the special registers have been modified, the transaction may be aborted.

Abstract: An HTM-assisted Combining Framework (HCF) may enable multiple (combiner and non-combiner) threads to access a shared data structure concurrently using hardware transactional memory (HTM). As long as a combiner executes in a hardware transaction and ensures that the lock associated with the data structure is available, it may execute concurrently with other threads operating on the data structure. HCF may include attempting to apply operations to a concurrent data structure utilizing HTM and if the HTM attempt fails, utilizing flat combining within HTM transactions. Publication lists may be used to announce operations to be applied to a concurrent data structure. A combiner thread may select a subset of the operations in the publication list and attempt to apply the selected operations using HTM. If the thread fails in these HTM attempts, it may acquire a lock associated with the data structure and apply the selected operations without HTM.

Abstract: A remove operation and an add-to-front operation may be currently performed with respect to nodes in an Least Recently Used (LRU) queue. A remove operation for a node may proceed if a lock can be obtained on the node to be removed and a predecessor node. During the remove operation, an add-to-front operation may proceed if a lock can be obtained on a dummy node that precedes the current front node of the LRU queue.

Abstract: A remove operation and an add-to-front operation may be currently performed with respect to nodes in an Least Recently Used (LRU) queue. A remove operation for a node may proceed if a lock can be obtained on the node to be removed and a predecessor node. During the remove operation, an add-to-front operation may proceed if a lock can be obtained on a dummy node that precedes the current front node of the LRU queue.

Abstract: A first data accessor acquires a lock associated with a critical section. The first data accessor initiates a help session associated with a first operation of the critical section. In the help session, a second data accessor (which has not acquired the first lock) performs one or more sub-operations of the first operation. The first data accessor releases the lock after at least the first operation has been completed.

Abstract: Transactional Lock Elision allows hardware transactions to execute unmodified critical sections protected by the same lock concurrently, by subscribing to the lock and verifying that it is available before committing the transaction. A “lazy subscription” optimization, which delays lock subscription, can potentially cause behavior that cannot occur when the critical sections are executed under the lock. Hardware extensions may provide mechanisms to ensure that lazy subscriptions are safe (e.g., that they result in correct behavior). Prior to executing a critical section transactionally, its lock and subscription code may be identified (e.g., by writing their locations to special registers). Prior to committing the transaction, the thread executing the critical section may verify that the correct lock was correctly subscribed to. If not, or if locations identified by the special registers have been modified, the transaction may be aborted.

Abstract: A remove operation and an add-to-front operation may be currently performed with respect to nodes in an Least Recently Used (LRU) queue. A remove operation for a node may proceed if a lock can be obtained on the node to be removed and a predecessor node. During the remove operation, an add-to-front operation may proceed if a lock can be obtained on a dummy node that precedes the current front node of the LRU queue.

Abstract: A system may perform work stealing using a dynamically configurable separation between stealable and non-stealable work items. The work items may be held in a double-ended queue (deque), and the value of a variable (index) may indicate the position of the last stealable work item or the first non-stealable work item in the deque. A thread may steal a work item only from the portion of another thread's deque that holds stealable items. The owner of a deque may add work items to the deque and may modify the number or percentage of stealable work items, the number or percentage of non-stealable work items, and/or the ratio between stealable and non-stealable work items in the deque during execution. For example, the owner may convert stealable work items to non-stealable work items, or vice versa, in response to changing conditions and/or according to various work-stealing policies.

Abstract: Socket scheduling modes may prevent non-uniform memory access effects from negatively affecting performance of synchronization mechanisms utilizing hardware transactional memory. Each mode may indicate whether a thread may execute a critical section on a particular socket. For example, under transitional lock elision, locks may include a mode indicating whether threads may acquire or elide the lock on a particular socket. Different modes may be used alternately to prevent threads from starving. A thread may only execute a critical section on a particular socket if allowed by the current mode. Otherwise, threads may block until allowed to execute the critical section, such as after the current mode changes. A profiling session may, for a running workload, iterate over all possible modes, measuring statistics pertaining to the execution of critical sections (e.g., the number of lock acquisitions and/or elisions), to determine the best performing modes for the particular workload.

Abstract: Threads using hardware transactions and executing instrumented critical sections that do not perform any writes may complete as long as the thread holding the lock has not yet executed its first write operation. If the thread executing the instrumented critical section performs any writes, or if the thread holding the lock performs any writes during its critical section, the hardware transaction may be aborted. A write flag may be used to determine whether the thread holding the lock performs any writes. The thread holding the lock may set the flag before performing any write operation. The thread executing the hardware transaction may subscribe to that flag and abort the transaction if the flag is set to true, indicating that the thread holding the lock performed a write operation.

Abstract: Systems and methods for implementing constrained data-driven parallelism may provide programmers with mechanisms for controlling the execution order and/or interleaving of tasks spawned during execution. For example, a programmer may define a task group that includes a single task, and the single task may define a direct or indirect trigger that causes another task to be spawned (e.g., in response to a modification of data specified in the trigger). Tasks spawned by a given task may be added to the same task group as the given task. A deferred keyword may control whether a spawned task is to be executed in the current execution phase or its execution is to be deferred to a subsequent execution phase for the task group. Execution of all tasks executing in the current execution phase may need to be complete before the execution of tasks in the next phase can begin.

Abstract: Transactional reader-writer locks may leverage available hardware transactional memory (HTM) to simplify the procedures of the reader-writer lock algorithm and to eliminate a requirement for type stable memory An HTM-based reader-writer lock may include an ordered list of client-provided nodes, each of which represents a thread that holds (or desires to acquire) the lock, and a tail pointer. The locking and unlocking procedures invoked by readers and writers may access the tail pointer or particular ones of the nodes in the list using various combinations of transactions and non-transactional accesses to insert nodes into the list or to remove nodes from the list. A reader or writer that owns a node at the head of the list (or a reader whose node is preceded in the list only by other readers' nodes) may access a critical section of code or shared resource.