Abstract: A reader of a set of data accessors that includes readers and writer detects that a particular lock of a first collection of non-global locks associated with a data object of a computing environment is held by another accessor. After checking a blocking indicator, the reader uses a second lock (which is not part of the first collection) to obtain read access to the data object and implements its reads without acquiring the particular lock. Prior to implementing a write on the data object, a writer acquires at least some locks of the first collection, and sets the blocking indicator to prevent readers from using the second lock to obtain read access to the data object.

Abstract: A computer comprising multiple processors and non-uniform memory implements multiple threads that perform a lock operation using a shared lock structure that includes a pointer to a tail of a first-in-first-out (FIFO) queue of threads waiting to acquire the lock. To acquire the lock, a thread allocates and appends a data structure to the FIFO queue. The lock is released by selecting and notifying a waiting thread to which control is transferred, with the thread selected executing on the same processor socket as the thread controlling the lock. A secondary queue of threads is managed for threads deferred during the selection process and maintained within the data structures of the waiting threads such that no memory is required within the lock structure. If no threads executing on the same processor socket are waiting for the lock, entries in the secondary queue are transferred to the FIFO queue preserving FIFO order.

Abstract: A computer comprising one or more processors and memory may implement multiple threads that perform a lock operation using a data structure comprising an allocation field and a grant field. Upon entry to a lock operation, a thread allocates a ticket by atomically copying a ticket value contained in the allocation field and incrementing the allocation field. The thread compares the allocated ticket to the grant field. If they are unequal, the thread determines a number of waiting threads. If the number is above the threshold, the thread enters a long term wait operation comprising determining a location for long term wait value and waiting on changes to that value. If the number is below the threshold or the long term wait operation is complete, the thread waits for the grant value to equal the ticket to indicate that the lock is allocated.

Abstract: Generic Concurrency Restriction (GCR) may divide a set of threads waiting to acquire a lock into two sets: an active set currently able to contend for the lock, and a passive set waiting for an opportunity to join the active set and contend for the lock. The number of threads in the active set may be limited to a predefined maximum or even a single thread. Generic Concurrency Restriction may be implemented as a wrapper around an existing lock implementation. Generic Concurrency Restriction may, in some embodiments, be unfair (e.g., to some threads) over the short term, but may improve the overall throughput of the underlying multithreaded application via passivation of a portion of the waiting threads.

Abstract: A method of forming an array comprising using two different composition masking materials in forming a pattern of spaced repeating first features of substantially same size and substantially same shape relative one another. A pattern-interrupting second feature of at least one of different size or different shape compared to that of the first features is within and interrupts the pattern of first features. The pattern of the first features with the pattern-interrupting second feature are translated into lower substrate material that is below the first features and the pattern-interrupting second feature. Material of the first features and of the pattern-interrupting second feature that is above the lower substrate material is removed at least one of during or after the translating.

Abstract: Concurrent threads may be synchronized at the level of the memory words they access rather than at the level of the lock that protects the execution of critical sections. Each lock may be associated with an array of flags and each flag may indicate ownership of certain memory words. A pessimistic thread may set flags corresponding to memory words it is accessing in the critical section, while an optimistic thread may read the corresponding flag before any memory access to ensure that the flag is not set and that therefore the associated memory word is not being accessed by the other thread. Thus, optimistic threads that do not have conflicts with the pessimistic thread may not have to wait for the pessimistic thread to release the lock before proceeding.

Abstract: A data object has a lock and a condition indicator associated with it. Based at least partly on detecting a first setting of the condition indicator, a reader stores an indication that the reader has obtained read access to the data object in an element of a readers structure and reads the data object without acquiring the lock. A writer detects the first setting and replaces it with a second setting, indicating that the lock is to be acquired by readers before reading the data object. Prior to performing a write on the data object, the writer verifies that one or more elements of the readers structure have been cleared.

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 authenticated modular map library may support partial state for a key-value store. A key-value store may be created that is organized as a tree data structure that divides items into pages. Features to access the key-value store may also be specified when the key-value store is created. A portion of the key-value store may be sent to a participant of a blockchain network, which may attempt to access an item to be found in a page in the key-value store according to the specified features. If the page is not included in the portion, the page may be requested from another participant, received, and verified before being used to complete the attempted access of the item.

Abstract: A computer comprising one or more processors and memory may implement an atomic compare and swap (CAS) operation on multiple data elements. Each data element has a corresponding descriptor which includes a new value and a reference to a controlling descriptor for the CAS operation. The controlling descriptor includes a status value which indicates whether the CAS operation is in progress or has completed. The operation first allocates memory locations of the data elements by writing addresses of respective descriptors to the memory locations using CAS instructions. The operation then writes successful status to the status value of the controlling descriptor to indicate that the respective memory locations are no longer allocated. The operation then returns an indicator of successful completion without atomically updating the memory locations with the new values. Extensions are further described to implement CAS operations in non-volatile random access memories.

Abstract: A computer system including one or more processors and persistent, word-addressable memory implements a persistent atomic multi-word compare-and-swap operation. On entry, a list of persistent memory locations of words to be updated, respective expected current values contained the persistent memory locations and respective new values to write to the persistent memory locations are provided. The operation atomically performs the process of comparing the existing contents of the persistent memory locations to the respective current values and, should they match, updating the persistent memory locations with the new values and returning a successful status. Should any of the contents of the persistent memory locations not match a respective current value, the operation returns a failed status. The operation is performed such that the system can recover from any failure or interruption by restoring the list of persistent memory locations.

Abstract: Hardware transactional memory (HTM) systems may guarantee that transactions commit without falling back to non-speculative code paths. A transaction that fails to progress may enter a power mode, giving the transaction priority when it conflicts with non-power-mode transactions. If, during execution of a power-mode transaction, another thread attempts, using a non-power-mode transaction, to access a shared resource being accessed by the power-mode transaction, it may be determined whether any actual data conflict occurs between the two transactions. If no data conflict exists, both transactions may continue to completion. If, however, a data conflict does exist, the power-mode transaction may deny the other transaction access to the shared resource. HTM systems may, in some embodiments, ensure that only one power-mode transaction exists at a time. In other embodiments, multiple, concurrent, power-mode transactions may be supported while ensuring that they access disjoint data sets.

Abstract: Systems and methods for secure transaction interfaces. In one implementation, a processing device receives, within a user input interface and while a user communication agent is presented at a display interface of a device, a selection of a transaction initiation control, presents, in response to the selection of the transaction initiation control and via the user input interface, a transaction execution control, presents, in response to a selection of the transaction execution control, identifier(s) via an identifier selection control, receives a selection of the identifier(s), transitions, in response to the selection of the identifier(s), the user input interface into a numeric input interface, receives a numeric input via the numeric input interface, activates a transaction confirmation control within the user input interface, and executes, in response to a selection of the transaction confirmation control, a secure transaction with respect to the selected identifier(s) and the numeric input.

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: Systems and methods for secure transaction interfaces. In one implementation, a processing device receives, within a user input interface and while a user communication agent is presented at a display interface of a device, a selection of a transaction initiation control, presents, in response to the selection of the transaction initiation control and via the user input interface, a transaction execution control, presents, in response to a selection of the transaction execution control, identifier(s) via an identifier selection control, receives a selection of the identifier(s), transitions, in response to the selection of the identifier(s), the user input interface into a numeric input interface, receives a numeric input via the numeric input interface, activates a transaction confirmation control within the user input interface, and executes, in response to a selection of the transaction confirmation control, a secure transaction with respect to the selected identifier(s) and the numeric input.

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: Generic Concurrency Restriction (GCR) may divide a set of threads waiting to acquire a lock into two sets: an active set currently able to contend for the lock, and a passive set waiting for an opportunity to join the active set and contend for the lock. The number of threads in the active set may be limited to a predefined maximum or even a single thread. Generic Concurrency Restriction may be implemented as a wrapper around an existing lock implementation. Generic Concurrency Restriction may, in some embodiments, be unfair (e.g., to some threads) over the short term, but may improve the overall throughput of the underlying multithreaded application via passivation of a portion of the waiting threads.

Abstract: A hardware-assisted mechanism may improve the performance of memory reclamation operations that employ hazard pointers. The mechanism includes hazard lookaside buffers (HLBs), each implemented in hardware and locally accessible to one or more processor cores, and two new instructions. A special store instruction may write entries to local HLBs for pointers that have been or will be dereferenced but were not yet written to a shared hazard table (which requires memory barriers). Each entry may include a hazard pointer and a table address. A special test instruction may signal each HLB to determine whether it contains a particular pointer and, if so, to return a response. If the pointer does not reside in any HLB, the memory reclamation operation may search the hazard table for the pointer. If the pointer is found in an HLB or in the hazard table, the pointed-to memory location or memory block is not reclaimed.

Abstract: A hardware-assisted mechanism may improve the performance of memory reclamation operations that employ hazard pointers. The mechanism includes hazard lookaside buffers (HLBs), each implemented in hardware and locally accessible to one or more processor cores, and two new instructions. A special store instruction may write entries to local HLBs for pointers that have been or will be dereferenced but were not yet written to a shared hazard table (which requires memory barriers). Each entry may include a hazard pointer and a table address. A special test instruction may signal each HLB to determine whether it contains a particular pointer and, if so, to return a response. If the pointer does not reside in any HLB, the memory reclamation operation may search the hazard table for the pointer. If the pointer is found in an HLB or in the hazard table, the pointed-to memory location or memory block is not reclaimed.

Abstract: Particular techniques for improving the scalability of concurrent programs (e.g., lock-based applications) may be effective in some environments and for some workloads, but not others. The systems described herein may automatically choose appropriate ones of these techniques to apply when executing lock-based applications at runtime, based on observations of the application in the current environment and with the current workload. In one example, two techniques for improving lock scalability (e.g., transactional lock elision using hardware transactional memory, and optimistic software techniques) may be integrated together. A lightweight runtime library built for this purpose may adapt its approach to managing concurrency by dynamically selecting one or more of these techniques (at different times) during execution of a given application.