Synchronization state buffer

Abstract

Efficient fine-grain synchronization is extremely important to effectively harness the computational power of many-core architectures. However, designing and implementing finegrain synchronization in such architectures presents several challenges, including issues of synchronization induced overhead, storage cost, scalability, and the level of granularity to which synchronization is applicable. This paper proposes the Synchronization State Buffer (SSB), a scalable architectural design for fine-grain synchronization that efficiently performs synchronizations between concurrent threads. The design of SSB is motivated by the following observation: at any instance during the parallel execution only a small fraction of memory locations are actively participating in synchronization. Based on this observation we present a finegrain synchronization design that records and manages the states of frequently synchronized data using modest hardware support. We have implemented the SSB design in the context of the 160-core IBM Cyclops-64 architecture. Using detailed simulation, we present our experience for a set of benchmarks with different workload characteristics.

MiSAR

“…Examples include accelerators for barriers [13,21,25] that track barrier's arrival state and detect the all-arrived condition without the overhead of updating the arrival count variable in a critical section. Lock accelerators [9,13,25,26] maintain the lock's owned/free state in hardware and thus help arbitrate which requestor is the next to get the lock once it is freed.…”

“…Several solutions have been adopted in prior work, such as requiring programmers to manually partition synchronization variables [1,4,7,9,17] into those that always use software and those that always use hardware, using the memory as a resource buffer [23], or switching to a software exception handler [26]. Unfortunately, programmer-implemented partitioning is not portable to architectures that have fewer resources, use of main memory complicates the implementation and adds latency, and software exception handlers are difficult to implement correctly and can incur large overhead when fallbacks are too frequent.…”

“…Several proposals have opted to use a software handler solution for hardware resource overflow [23,26]. They utilize two bits (FBIT/SBIT) to record the status of each slice of accelerator.…”

“…Numerous hardware mechanisms for low-latency synchronization have been proposed [7,12,20] and even used in prototype and commercial supercomputing machines [3,5,6,11,14,15,22]. As generalpurpose processors have shifted their focus from solely increasing single-core performance to providing more cores, there has been a renewed interest in hardware support for synchronization [1,2,17,23,26], this time for a much broader range of systems, programmers, and users. Examples of recently proposed hardware synchronization mechanisms include utilizing a small buffer attached to the on-chip memory controller to perform synchronization and allow trylock support [26], incorporating a lock control unit to both the core and memory controller to allow efficient reader-writer lock [23], or leveraging low latency signal propagation over transmission lines for lock and barrier synchronization [1,2,17].…”

Programming models for many-core architectures: a co-design approach

“…Stoif et al use a central memory controller where processors compete for protected memory regions [103]. The memory controller can also be extended to manage the state of synchronization data units that reside in the memory [82,121]. Tumeo et al implement synchronization using engines like the Xilinx mutex component [109].…”