#186 ThreadingModel is largely ignored by AllocatorSingleton

open
nobody
None
8
2012-12-03
2012-11-30
Tja Poeh
No

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.

Discussion

  • Tja Poeh
    Tja Poeh
    2012-12-03

    This seem a critical bug to me. The problem becomes very clear once you use a LokiAllocator in two different threads. The problem is that it makes use of AllocatorSingleton, so this is the same instance in the two threads, at least if the chunk sizes are identical. Allocations or deallocations from different threads are thus handled by the same allocator without doing any locking.

     
  • Tja Poeh
    Tja Poeh
    2012-12-03

    • priority: 5 --> 8
     
  • Tja Poeh
    Tja Poeh
    2012-12-03

    I seem to be able to work around the problem by adding mutex locks to LokiAllocator::Allocate() and LokiAllocator::Deallocate(). Unfortunately, this is devastating for the performance of the allocator.
    I guess the better solutions is not to use AllocatorSingleton, but to create a new allocator instance for each LokiAllocator. This should only be necessary in a multi-threaded model.

     
  • Tja Poeh
    Tja Poeh
    2012-12-03

    The solution to add mutex locks to LokiAllocator::Allocate en Deallocate actually turns out quite ok if I replace Loki's default Mutex (which on Windows is a CriticalSection) by a CMutex. Although the performance is about 50% of that without the lock, at least it's now functioning correctly.

     
  • Tja Poeh
    Tja Poeh
    2012-12-03

    Ah, it turns out I had forgotten to remove a change I had made locally in Loki's Mutex class. After removing those changes the CriticalSection performs better than CMutex, as was to be expected.

    Conclusion: The problem is solved by adding mutex locks to LokiAllocator::Allocate en LokiAllocator::Deallocate.