Oracle International Corporation

Oracle America, Inc.

Sun Microsystems, Inc.

Amazon Technologies, Inc.

David Dice

Alex Kogan

Nir N Shavit

Yosef Lev

Virendra J Marathe

Mark S Moir

Mark Sean Moir

Victor M Luchangco

Timothy Lawrence Harris

Alexander T Garthwaite

Daniel Nussbaum

Ronald J Mann

Pantea Zardoshti

Paul N Loewenstein

Maurice P Herlihy

Antonios Printezis

Paul Henry Hohensee

Martin Karlsson

Ori Shalev

Shady Alaaeldin Mohamed Abdelkader Rabie Issa

Yujie Liu

Robert G Vandette

Timothy M Merrifield

Daniel McNaught Jordan

John Robert Rose

Oleksandr Otenko

Christine H Flood

Srikanta Tirthapura

Timothy Paul Marsland

Irina Calciu

Kevin Moore

Hui Huang

David L Reese

James R Goodman

David K Aha

David B Therkelsen

Sunil Sreenivasan

Mark A Moir

Andrew F Herrick

Hamid Mozaffari

Derek R White

William N Scherer, Iii

Mingyao Yang

Mandy L Chung

Paula J Bishop

Parameter permutation is performed for federated learning to train a machine learning model. Parameter permutation is performed by client systems of a federated machine learning system on updated parameters of a machine learning model that have been updated as part of training using local training data. An intra-model shuffling technique is performed at the client systems according to a shuffling pattern. Then, the encoded parameters are provided to an aggregation server using Private Information Retrieval (PIR) queries generated according to the shuffling pattern.

Federated learning by parameter permutation

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. Nested critical sections associated with different lock types may invoke different subscription code.

Systems and methods for safely subscribing to locks using hardware extensions

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.

Critical section speedup using help-enabled locks

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.

Global secondary path locking technique enabling high read concurrency for read-mostly workloads

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.

Compact NUMA-aware locks

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.

Reader bias based locking technique enabling high read concurrency for read-mostly workloads

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.

Ticket locks with enhanced waiting

A concurrency-restricting lock may divide a set of threads waiting to acquire the lock into an active circulating set (ACS) that contends for the lock, and a passive set (PS) that awaits an opportunity to contend for the lock. The lock, which may include multiple constituent lock types, lists, or queues, may be unfair over the short term, but improve throughput of the underlying multithreaded application. Culling and long-term fairness policies may be applied to the lock to move excess threads from the ACS to the PS or promote threads from the PS to the ACS. These policies may constraint the size or distribution of threads in the ACS (which may be NUMA-aware). A waiting policy may avoid aggressive promotion from the PS to the ACS, and a short-term fairness policy may move a thread from the tail of a list or queue to its head.

Systems and methods for performing concurrency restriction and throttling over contended locks

Compact and scalable mutual exclusion techniques are implemented for multiple executing threads. A thread may acquire a lock by swapping a pointer to the thread into a tail field of a lock data structure. If the swap operation returned a null value, then the lock is acquired. If the swap operation does not return a null value, then the thread may wait to obtain the lock from a predecessor thread. The thread may wait until a grant field in a data structure for the predecessor thread stores a pointer to the lock, signaling to the thread that the thread may acquire the lock.

System and method for acquiring and releasing a lock using compact and scalable mutual exclusion

NUMA-aware reader-writer locks may leverage lock cohorting techniques that introduce a synthetic level into the lock hierarchy (e.g., one whose nodes do not correspond to the system topology). The synthetic level may include a global reader lock and a global writer lock. A writer thread may acquire a node-level writer lock, then the global writer lock, and then the top-level lock, after which it may access a critical section protected by the lock. The writer may release the lock (if an upper bound on consecutive writers has been met), or may pass the lock to another writer (on the same node or a different node, according to a fairness policy). A reader may acquire the global reader lock (whether or not node-level reader locks are present), and then the top-level lock. However, readers may only hold these locks long enough to increment reader counts associated with them.

System and method for promoting reader groups for lock cohorting

A computer comprising one or more processors and memory may implement multiple threads performing mutually exclusive lock acquisition operations on disjoint ranges of a shared resource each using atomic compare and swap (CAS) operations. A linked list of currently locked ranges is maintained and, upon entry to a lock acquisition operation, a thread waits for all locked ranges overlapping the desired range to be released then inserts a descriptor for the desired range into the linked list using a single CAS operation. To release a locked range, a thread executes a single fetch and add (FAA) operation. The operation may be extended to support simultaneous exclusive and non-exclusive access by allowing overlapping ranges to be locked for non-exclusive access and by performing an additional validation after locking to provide conflict resolution should a conflict be detected.

Scalable range locks

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.

Generic concurrency restriction

A computer including multiple processors and memory implements a managed runtime providing a synchronization application programming interface (API) for threads that perform synchronized accesses to shared objects. A standardized header of objects includes a memory word storing an object identifier. To lock the object for synchronized access, the memory word may be converted to store the tail of a linked list of a first-in-first-out synchronization structures for threads waiting to acquire the lock, with the object identifier relocated to the list structure. The list structure may further include a stack of threads waiting on events related to the object, with the synchronization API additionally providing wait, notify and related synchronization operations. Upon determining that no threads hold or desire to hold the lock for the object and that no threads are waiting on events related to the object, the memory word may be restored to contain the object identifier.

Compact synchronization in managed runtimes

Growing community of inventors

Foxboro, MA, United States of America

David Dice