title: Are spinlocks a good choice for a memory allocator?
body: <p>I've suggested to the maintainers of the D programming language runtime a few times that the memory allocator/garbage collector should use spinlocks instead of regular OS critical sections.  This hasn't really caught on.  Here are the reasons I think spinlocks would be better:</p>
  
  <ol>
  <li>At least in synthetic benchmarks that I did, it's several times faster than OS critical sections when there's contention for the memory allocator/GC lock.  Edit:  Empirically, using spinlocks didn't even have measurable overhead in a single-core environment, probably because locks need to be held for such a short period of time in a memory allocator.</li>
  <li>Memory allocations and similar operations usually take a small fraction of a timeslice, and even a small fraction of the time a context switch takes, making it silly to context switch in the case of contention.</li>
  <li>A garbage collection in the implementation in question stops the world anyhow.  There won't be any spinning during a collection.</li>
  </ol>
  
  <p>Are there any good reasons <strong>not</strong> to use spinlocks in a memory allocator/garbage collector implementation?</p>