A surprise with mutexes and reference counts

One way approach is to use a deferred-reclamation scheme, such as RCU (my personal favorite), SLAB_DESTROY_BY_RCU, hazard pointers (Maged Michael's personal favorite), a general-purpose garbage collector, or even the rough-and-ready approach of simply never freeing any memory. Another approach is to make use of a lock or reference counter that lives outside of the memory being protected, the so-called "hand-over-hand locking" being one (slow!) example, and hashed arrays of locks being another (also slow!) example. Yet another approach is to use a scheme that allows the reference-count increment to proceed only if the pointer to the memory remains unchanged, for example, using MC68020's dcas instruction or one of the transactional-memory approaches. Of course, in the case of transactional memory, make sure to take into account the forward-progress properties!

If the only protection for a piece of memory is a lock inside that piece of memory, life is hard. As far as I know, Gamsa et al. were the first to point this out in their 1999 OSDI paper: http://www.usenix.org/events/osdi99/full_papers/gamsa/gam....