Review: Performance Implications of Thread Management

From: Steve Arnold (steve.arnold4_at_verizon.net)
Date: Sun Jan 25 2004 - 19:35:23 PST

  • Next message: Joanna Muench: "Review of Performance Implications of Thread Management Alternatives"

    In their paper, the authors discuss some basic techniques to thread
    management. In the first section, they discuss different alternatives to
    thread management (thread libraries). The first, single lock, is the most
    basic. The second, multiple locks, allows each processor to have its own
    lock. The third, Local Free Lists, has a list for each process that requires
    no locking, while there is a central one that does. The fourth, Idle Queue,
    is where you keep a list of free processors that can be ready once threads
    are ready. The last is Local Ready Queue, where everything is based at the
    processor. In their basic tests, they found the local ready queue to most
    quickly complete a simple benchmark.
     
    After dicussing these alternatives, the authors go on to discuss three
    alternatives to spin-locking. Spin locking has implications to other
    threads, as well as bus contention. In the end, the authors seem to lean
    toward an "Ethernet-Style Backoff" system, even though it is unfair.
     
    This paper seems that it might have been one of the first in-depth analysis
    of managing lightweight threads (past papers were concerned mostly with
    multiprogramming processes). Today it seems like we don't think much of
    this, but these are important concepts to achieving better performance.
     
    I would like to have seen more advanced benchmarks and simulations, although
    I'm not sure that was their point in this paper. Also, some conclusions were
    based on architecture-dependent assumptions. It seems like this analysis
    should be done in conjunction with looking at architecture alternatives.
     


  • Next message: Joanna Muench: "Review of Performance Implications of Thread Management Alternatives"

    This archive was generated by hypermail 2.1.6 : Sun Jan 25 2004 - 19:35:13 PST