# CAL: Core-Aware Lock for the big.LITTLE Multicore Architecture
## 5 Related Work  
Locks continue to serve as the prevailing mechanism for synchronization in concurrent systems at present and have been widely studied for various application scenarios in recent years. However, these research-works on lock algorithm for the big.LITTLE multicore architecture has not been studied widely. **Lock algorithms for NUMA. ** In recent years, the advent of NUMA architecture has brought unignorable challenges in the design of lock algorithms specifically tailored for such systems. [PERSON] et al. [10] designed a general lock scheme for NUMA architecture: cohort lock. Cohort lock consists of a unique global lock and a local lock for each NUMA node. Global lock must meet thread-oblivious characteristics (i.e., the locking thread and the unlocking thread can be different). The local lock must incorporate cohort detection capabilities (i.e., the thread needs to detect whether there are waiting threads). Cohort lock allows local locks to be passed within the same NUMA node, thereby minimizing cross-node traffic overhead. Furthermore, it incorporates periodic switching between NUMA nodes to achieve long-term fairness. [PERSON] et al. design a hierarchical backoff lock (HBO) based on cohort locks [25], which is a ttas lock with a backoff scheme to reduce cross-node lock contention. [PERSON] et al. propose shuffling [15], which decouples lock design from policy execution, such as NUMA awareness and parking/waking policies, to achieve high performance without increasing memory overhead. The above lock algorithms are designed for NUMA architecture, considering the inconsistent memory costs of different nodes in the NUMA architecture, while periodically switching NUMA nodes to ensure long-term fairness. However, the inherent asymmetry of the big.LITTLE architecture results in throughput descension when big and little cores are allocated to different NUMA nodes, as detailed in Section 2.3. Therefore, these lock algorithms fail to be adopted in big.LITTLE multicore architecture. Figure 9: Comparison in LevelDB. (**a**) Fairness. (**b**) Throughput and tail latency. **Delegation-based lock algorithms. ** This lock employs a thread to delegate the right to enter a critical section to other thread, thereby enhancing the cache locality of critical section operations and demonstrating improved adaptability under extreme lock contention scenarios. [PERSON] et al. (2020) design Remote Call Locks (RCL) locks to accelerate the execution of critical section of applications on multicore architectures. The idea of RCL is to replace lock acquisition by optimizing remote calls to dedicated server hardware threads. RCL effectively mitigates performance crashes when multi-threads try to acquire locks and eliminates the necessity of transferring shared data to server threads since such data often remains cached within the server cache. [PERSON] et al. (2020) discussed the problem of delegation and synchronous access to shared memory and found that delegation locking is much faster than traditional locking in a series of common cases. They proposed ffwd, a fast and lightweight delegation lock, which boasts a highly optimized design that sustains scalability advantages. Although delegation-based algorithms can accelerate the processing of server threads, they require a lot of polling, potentially leading to high latency in the case of poor network conditions. Moreover, these algorithms necessitate that critical sections be formulated as closures, augmenting the intricacy and complexity of the programming task. Therefore, the delegation-based approach is not suitable for big.LITTLE architecture. **Automatically tuned locking algorithms. ** Automatically tuned locking algorithms would automatically tune some internal parameters at runtime. For example, reaction locking tunes the back-off time in spinlock to reduce contention, and mutlock adjusts the number of busy spinning threads to hide the wake-up latency in blocking locks. [PERSON] et al. (2020) set the spin threshold before blocking to obtain better throughput.