I've been thinking about how to implement this and I think I know the approach I should take but wanted to ask here anyway.  TDPL implies that this function is for owner-ownee relationships so nodes in a List class, for example, can all share the same mutex as the List class itself.  However, there's nothing stopping a user from linking any two objects together and I'm wondering if I should support this as well.

The default object monitor is allocated from the C malloc pool so synchronized statements are legal within the object dtor.  Because of this, sharing the monitor between two classes means adding reference counting to know when to actually clean up the monitor.  What I'm wondering is how careful I have to be about synchronizing the reference count.  If setSameMutex is only called within the context of an owner-ownee relationship then it's reasonable to assume that the monitor will be locked whenever a node is created and setSameMutex is called, so no additional synchronization of the refcount should be necessary.  I'm guessing I should instead be paranoid and treat this whole thing like a shared_ptr for safety's sake, but if the performance hit isn't necessary considering the intent of setSameMutex then I'd prefer not to bother.

Thoughts?

Implemented using an atomic refcount.  Still haven't applied "shared" more broadly to the code yet though.  It seems difficult to do that in pieces.