Mv spin locks

Status

• development started August 21, 2013

History / Context

For performance discussions, it is best to assume Erlang's schedulers run continuous busy wait loops. The continuing thought is that performance is lost anytime leveldb gives up a its time slice to a spinning Erlang scheduler. This branch begins the conversion of tight threading synchronization points from pthread_mutex_t to pthread_spinlock_t. pthread_spinlock_t keeps the time slice with the current thread instead of going to sleep and causing a longer spin within Erlang.

Not all platforms support pthread_spinlock_t. Google established good rules for platform specific implementation. The new Spin and SpinLock classes build upon the Google code. Where pthread_spinlock_t is not available, the new Spin and SpinLock classes default to using the established Mutex class under the covers. Example: Mac OSX does not support pthread_spinlock_t and therefore continues to use pthread_mutex_t.

This branch only changes Mutex to Spin within util/cache.cc. This alone has demonstrated performance improvements for leveldb iterators used by Riak AAE and 2i features.

Implementation

port/port_posix.h is where the implementation support / logical switch occurs. The new class Spin only gets defined if the proper C feature defines exist. If they do not exist, class Spin becomes a synonym for Google's Mutex class.

util/mutexlock.h and util/mutexlock.cc contain the declaration and implementation respectively for the new SpinLock class. This new class ultimately uses either the Spin or Mutex class based upon the compile time decisions of port/port_posix.h. SpinLock is a straight copy of the MutexLock class with name changes. There is no logic difference.

util/cache.cc is the first user of the new Spin and SpinLock classes. Every Mutex and MutexLock in this file was globally changed to Spin and SpinLock. The id_mutex_ (now id_spin_) usage should really be replaced with an atomic increment. But that is a different, future branch.