King_DuckZ/Loki
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

Added comment explaining why ObjectLevelLockable policy does not work for singletons.

Browse source 
git-svn-id: svn://svn.code.sf.net/p/loki-lib/code/trunk@774 7ec92016-0320-0410-acc4-a06ded1c099a
This commit is contained in:
rich_sposato 2006-11-03 00:52:31 +00:00
parent 337f50ba9d
commit 92daa47cbd
1 changed files with 13 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

15
include/loki/SmallObj.h
View file

@ -345,6 +345,17 @@ namespace Loki
or derived from by clients. Class has no data members so compilers can
use Empty-Base-Optimization.
@par ThreadingModel
This class doesn't support ObjectLevelLockable policy for ThreadingModel.
The allocator is a singleton, so a per-instance mutex is not necessary.
Nor is using ObjectLevelLockable recommended with SingletonHolder since
the SingletonHolder::MakeInstance function requires a mutex that exists
prior to when the object is created - which is not possible if the mutex
is inside the object, such as required for ObjectLevelLockable. If you
attempt to use ObjectLevelLockable, the compiler will emit errors because
it can't use the default constructor in ObjectLevelLockable. If you need
a thread-safe allocator, use the ClassLevelLockable policy.
@par Lifetime Policy
The SmallObjectBase template needs a lifetime policy because it owns
@ -399,10 +410,10 @@ namespace Loki
- Both Small-Object and Singleton use NoDestroy policy.
Since neither is ever destroyed, the destruction order does not matter.
Note: yow will get memory leaks!
Note: you will get memory leaks!
- The Small-Object has NoDestroy policy but the Singleton has
SingletonWithLongevity policy. Note: yow will get memory leaks!
SingletonWithLongevity policy. Note: you will get memory leaks!
You should *not* use NoDestroy for the singleton, and then use