[ loki-lib-Bugs-3591349 ] ThreadingModel is largely ignored by AllocatorSingleton

[SourceForge.net <no...@so...>]

Bugs item #3591349, was opened at 2012-11-30 05:45
Message generated for change (Comment added) made by tjapoeh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3591349&group_id=29557

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 8
Private: No
Submitted By: Frank Olthuis (tjapoeh)
Assigned to: Nobody/Anonymous (nobody)
Summary: ThreadingModel is largely ignored by AllocatorSingleton

Initial Comment:
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.


----------------------------------------------------------------------

>Comment By: Frank Olthuis (tjapoeh)
Date: 2012-12-03 05:46

Message:
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.

----------------------------------------------------------------------

Comment By: Frank Olthuis (tjapoeh)
Date: 2012-12-03 02:38

Message:
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.

----------------------------------------------------------------------

Comment By: Frank Olthuis (tjapoeh)
Date: 2012-12-03 02:22

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3591349&group_id=29557