Queue-Based and Adaptive Lock Algorithms for Scalable Resource Allocation on Shared-Memory Multiprocessors

Abstract

We present a scalable lock algorithm and an adaptive scheme for shared-memory multiprocessors addressing the resource allocation problem, which is also known as the $h$-out-of-$k$ mutual exclusion problem. In this problem, threads compete for $k$ shared resources where a thread may request an arbitrary number $1\le h\le k$ of resources at the same time. The challenge is for each thread to acquire exclusive access to desired resources while preventing deadlock or starvation. Many existing approaches solve this problem in a distributed system, but the explicit message passing paradigm they adopt is not optimal for shared-memory. Other applicable methods, like two-phase locking and resource hierarchy, suffer from performance degradation under heavy contention, while lacking a desirable fairness guarantee. This work describes the first multi-resource lock algorithm that guarantees the strongest first-in, first-out fairness. Our methodology is based on a non-blocking queue where competing threads spin on previous conflicting resource requests. In our experimental evaluation we compared the overhead and scalability of our lock to the best available alternative approaches using a micro-benchmark. As contention increases, our multi-resource lock obtains an average of eight times speed-up over the alternatives including GNU C++’s lock method, Boost’s lock function, and Intel TBB’s queue mutex. To further improve the performance on low levels of contention, we introduce an adaptive scheme that is composed of two different lock algorithms and alternates the use the locks depending on the level of contention. Our experimental results show that the composite adaptive scheme achieves the best overall performance comparing with using either lock alone when system contention is not known a priori.

Appendix: Hardware Transactional Memory with MRLock as Fallback

1.1 Outline

Intel’s Transactional Synchronization Extensions (TSX) offer support for a best-effort transactional memory. With Intel TSX, the processor executes transactions optimistically in hardware without explicit serialization. In situations of low contention, the majority of the transactional regions of code will be able to successfully and efficiently commit to memory using HTM. As contention increases, transactional aborts will also increase due to detected data conflicts. Performance degradation is evident when transactions continuously abort. It is common practice to place a limitation on the total number of allowed aborts. Transactions that reach this limit should be re-routed towards a software execution path. Intel 64 and IA-32 Architectures Optimization Reference Manual recommends a wrapper for lock elision using TSX where transactions that do not successfully elide the lock must acquire a global lock to commit to memory. While the use of a global lock offers a solution, it is not scalable due to limited concurrency that is associated with global serialization of critical sections.

In order to apply MRLock as the software fallback path, we define a resource to be a shared memory location that is part of a transaction’s read- and/or write-set, and each transactional resource is dynamically mapped to a bit in a bitset. We use an unordered mapping scheme where each element of the unordered map stores a memory address as the key and the assigned bit position as the mapped value. Transactions are initially executed using TSX. Once a transaction has reached the maximum allowed attempts to commit using HTM, it will be executed by our multi-resource lock manager. It is essential that transactions executing in hardware and software safely interact with each other in order to protect data integrity. We guarantee correct behavior by efficiently traversing the MRLock queue prior to every transaction attempted using HTM. During the queue traversal, we check for any conflicts between the enqueued requests and the bitset request of the pending transaction. If no conflicts exist, the transaction may safely proceed with the execution in hardware. Otherwise, the transaction is explicitly aborted and will wait for all conflicting requests to commit to memory before a retry.

1.2 Evaluation

Performance experiments are performed on a Fourth Generation Intel Core™ processor with Intel TSX support. We evaluate our approach on a micro-benchmark consisting of read/write operations on an array. A similar benchmark was used by Matveev and Shavit [29] where transactions read and write to random locations of a shared array. The transactional regions within the micro-benchmark are short, delivering a practical representation of the intended usage of Intel TSX. Sufficient resources are provided by Intel TSX to commit a common transactional region to memory. However, a transaction that exceeds the capacity limitations will experience frequent aborts. Each thread randomly selects h unique array positions to increment out of k total array positions. The resource contention is denoted by the fraction h/k. The array incrementation is performed within a loop, where the loop iteration count is set to 10,000. We vary the number of total resources between 4 $\le$ k $\le$ 64 and the number of resource requests between 4 $\le$ h $\le$ k. We compare our approach against Rochester Software Transactional Memory (RSTM) [28] and a Hybrid HTM-STM [9].

Figure 7, shows performance scaling when increasing the resource contention at two, four, and eight threads. The y-axis represents the execution time at a logarithmic scale. The x-axis represents various resource contention ratios, where the labeled tick mark indicates the total available resources. The data plotted in the region to the left of the tick mark demonstrates the performance results for resource requests varied between 4 $\le$ h $\le$ k, where the total available resources, k, is indicated by the right-most tick mark. We test the proposed methodology using both std::unordered_map and Intel TBB concurrent_hashmap for the dynamic hashing scheme. The Hybrid HTM-STM follows a similar trend pattern to RSTM, but consistently under-performs the pure software transactional memory counterpart. This result is expected because the Hybrid HTM-STM must check the ownership record table prior to every read or write performed in a hardware transaction. The hardware transactions performed in the hybrid approach will explicitly abort themselves if a conflict is detected with an ongoing software transaction, yielding a bias towards transactions committing in software rather than hardware. RSTM and the Hybrid HTM-STM both show an increase in execution times following a logarithmic trend when increasing the resource contention ratio.

Fig. 7

Performance scaling. a 2 Threads b 4 Threads c 8 Threads

As the number of threads are increased, the contention for reads and writes on the array will also increase. Figure 7a shows that we have slower execution times than both RSTM and Hybrid HTM-STM at two threads until the resource contention ratio reaches approximately 1/8. Once the resource contention ratio increases beyond 1/8, we maintain a faster execution time than both RSTM and Hybrid HTM-STM. Figure 7b shows the results when scaling the thread count up to four threads. Our approach yields slower execution times to RSTM and Hybrid HTM-STM at the 4/k configuration, but maintains faster execution times for all other configurations. At eight threads, Fig. 7c demonstrates that we outperform RSTM and Hybrid HTM-STM at all configurations.