ffwd

A scalable lock on NUMA multicore

“…Second, if it reserves one core for multiple lock instances, this can lead to false serialization 7,10 . Besides, we observe that ever the fastest delegation scheme, FFWD, 8 does not scale under extreme high contention for NUMA multicore machines, due to frequent crossnode communication between the server and client threads. On the contrary, dynamic delegation behaves without dedicating a core to a server, whereas the existing schemes either provide nonscalable performance 4,5 or offer less portability 10 …”

“…However, on NUMA machines, the execution for critical sections with less scaled locking schemes can easily cause performance collapse under high locking contention. As a result, there are many researches focusing on improving the scalability performance of locks, 1,4‐23 for which the most efficient alternatives are hierarchical NUMA‐aware locks and delegation locks on NUMA multicore systems. Hierarchical locks consist of local locks each synchronizing threads running on the same NUMA node and a global lock synchronizing threads holding a local lock.…”

“…Delegation can be classified into two categories: static delegation and dynamic delegation. Static delegation schemes 6‐8 dedicate one core to the server thread and other cores are used for client threads. The gain is that the shared data does not migrate between server and client cores.…”

“…This work proposes a delegation scheme, called DYLOCK, which occupies no cores while providing better scalable performance than static delegation schemes under extreme high locking contention on NUMA multicore machines. The DYLOCK is a variant of the most efficient delegation lock FFWD, 8 in which a dedicated core is used to running the server thread that processes requests in a round‐robin, node‐batched fashion, dealing with any new requests from one NUMA node before proceeding to the next. In DYLOCK, we employ dynamic server thread technique where a normal thread becomes the temporary server by acquiring one local lock per NUMA node and a global lock shared by all NUMA nodes.…”

“…The server thread reverts back to the normal thread by releasing the global lock and the local lock. The server thread processes the requests from the node on which it is running by employing a batch technique 8 . Communication between the server and client threads uses an array to store requests for the execution of critical sections without performing atomic instructions.…”