One would expect allocations and deallocations to be guarded when either the ClassLevelLockable or ObjectLevelLockable policy is specified for an AllocatorSingleton. This is not the case though. A few functions are guarded, such as creation of the singleton and
AllocatorSingleton is derived from SmallObjAllocator, which knows nothing whatsoever about threading models. This suggests that any mutex locking should be taken care of by AllocatorSingleton, which does know about the threading model. Alternatively, knowledge of locking could be moved to SmallObjAllocator.
In both cases this would imply that the locking which is now done in SmallObject itself should be moved to its allocator.