Managed Runtime Synchronization API with Thread-Local Lock Nodes
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Modern computer systems face challenges in providing synchronization for shared objects across multiple threads while minimizing memory overhead, as existing solutions either introduce additional memory usage or performance issues under access contention.
Innovation Solution
A synchronization API that moves synchronization data into thread-associated nodes, using a linked list structure within a memory word of the object to manage thread access, allowing for low-latency synchronization with minimal memory growth and zero object memory overhead, similar to the Mellor-Crummey and Scott (MCS) lock approach.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If synchronization data is stored in objects to support concurrent access, then synchronization capability is improved, but memory overhead increases
Solution Approach 1:
The patent extracts synchronization data from object storage and relocates it to thread-local storage structures. Specifically, synchronization state is moved from object fields to thread-specific lock records and wait queues, eliminating the need for objects to allocate memory for synchronization purposes while maintaining full synchronization functionality.
Solution Approach 2:
The patent introduces thread-local synchronization structures as intermediaries between threads and shared objects. These structures act as mediators that manage synchronization state without requiring the objects themselves to store synchronization data, thus decoupling synchronization overhead from object memory footprint.
2Adaptability or versatility
If dynamic memory expansion is used to support synchronization, then synchronization flexibility is improved, but performance degradation occurs
Solution Approach 1:
The patent pre-allocates thread-local synchronization structures when threads are created, rather than expanding memory dynamically when synchronization is first needed. This preliminary allocation eliminates runtime memory expansion overhead and ensures that synchronization operations can proceed with minimal latency.
Solution Approach 2:
The patent implements dynamic synchronization support through thread-local data structures that can grow and shrink based on actual synchronization needs, while keeping object memory footprint static. The system dynamically manages synchronization state in thread-local storage rather than in object memory, achieving both flexibility and performance.
3Reliability
If synchronization structures are added to objects, then access control is improved, but memory footprint growth occurs
Solution Approach 1:
The patent extracts all synchronization-related data from object storage and places it in thread-local structures. Lock state, wait queue information, and notification data are all stored in thread-specific records rather than in the objects being synchronized, completely eliminating synchronization-induced memory footprint growth for objects.
Solution Approach 2:
The patent implements local quality by making synchronization storage thread-local rather than object-global. Each thread maintains its own synchronization state and wait queue information in local data structures, allowing the system to provide robust access control while keeping each object's memory footprint independent of synchronization requirements.
Data Source
AI summary
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.