• Summary
• Related Documents
  • Active Bibliography
  • Co-citation
• Version History

Abstract:

We enhance the well established software combining synchronization technique to create combining funnels. Previous software combining methods used a statically assigned tree whose depth was logarithmic in the total number of processors in the system. On a shared memory multiprocessors the new method allows to dynamically build combining trees with depth logarithmic in the actual number of processors accessing the data structure concurrently. The structure is comprised from a series of combining layers through which processor's requests are funneled. These layers use randomization instead of a rigid tree structure to allow processors to find partners for combining. By using an adaptive scheme the funnel can change width and depth to accommodate different access frequencies without requiring global agreement as to its size. Rather, processors choose parameters of the protocol privately, making this scheme very simple to implement and tune. When we add an "elimination " mechanism to the funnel structure, the randomly constructed "tree " is transformed into a "forest " of disjoint (and on average shallower) trees of requests, thus enhancing the level of parallelism and decreasing latency. We present two new linearizable combining funnel based data structures: a fetch-and-add object and a stack. We study the performance of these structures by benchmarking them against the most efficient software implementations of fetchand-add and stacks known to date, combining trees and elimination trees, on a simulated shared memory multiprocessor using Proteus. Our empirical data shows that combining funnel based fetch-and-add outperforms combining trees of fixed height by as much as 70%. In fact, even compared to combining trees optimized for a given load, funnel performance is the same or better. Elimination trees, which are not linearizable, are 10 % faster than funnels under highest load, but as load drops combining funnels adapt their size, giving them a 34 % lead in latency.

Citations