update documentation due to the new lifetime policies

git-svn-id: svn://svn.code.sf.net/p/loki-lib/code/trunk@360 7ec92016-0320-0410-acc4-a06ded1c099a
This commit is contained in:
syntheticpp 2005-11-13 16:51:22 +00:00
parent a1b035fd15
commit a966dc9aff

View file

@ -56,20 +56,20 @@ namespace Loki
namespace LongevityLifetime namespace LongevityLifetime
{ {
/** @struct DieAsSmallObjectParent /** @struct DieAsSmallObjectParent
@ingroup SmallObjectGroup @ingroup SmallObjectGroup
Lifetime policy to manage lifetime dependencies of Lifetime policy to manage lifetime dependencies of
SmallObject base and child classes. SmallObject base and child classes.
The Base class should have this lifetime The Base class should have this lifetime
*/ */
template <class T> template <class T>
struct DieAsSmallObjectParent : DieLast<T> {}; struct DieAsSmallObjectParent : DieLast<T> {};
/** @struct DieAsSmallObjectChild /** @struct DieAsSmallObjectChild
@ingroup SmallObjectGroup @ingroup SmallObjectGroup
Lifetime policy to manage lifetime dependencies of Lifetime policy to manage lifetime dependencies of
SmallObject base and child classes. SmallObject base and child classes.
The Child class should have this lifetime The Child class should have this lifetime
*/ */
template <class T> template <class T>
struct DieAsSmallObjectChild : DieDirectlyBeforeLast<T> {}; struct DieAsSmallObjectChild : DieDirectlyBeforeLast<T> {};
@ -298,42 +298,81 @@ namespace Loki
/** @class SmallObjectBase /** @class SmallObjectBase
@ingroup SmallObjectGroupInternal @ingroup SmallObjectGroup
Base class for small object allocation classes. Base class for small object allocation classes.
The shared implementation of the new and delete operators are here instead The shared implementation of the new and delete operators are here instead
of being duplicated in both SmallObject or SmallValueObject. This class of being duplicated in both SmallObject or SmallValueObject, later just
is not meant to be used directly by clients, or derived from by clients. called Small-Objects. This class is not meant to be used directly by clients,
Class has no data members so compilers can use Empty-Base-Optimization. or derived from by clients. Class has no data members so compilers can
use Empty-Base-Optimization.
@par Singleton Lifetime Policies and Small-Object Allocator @par Lifetime Policy
At this time, the only Singleton Lifetime policies recommended for
use with the Small-Object Allocator are Loki::SingletonWithLongevity and The SmallObjectBase template needs a lifetime policy because it owns
Loki::NoDestroy. The Loki::DefaultLifetime and Loki::PhoenixSingleton a singleton of SmallObjAllocator which does all the low level functions.
policies are *not* recommended since they can cause the allocator to be When using a Small-Object in combination with the SingletonHolder template
destroyed and release memory for singletons which inherit from either you have to choose two lifetimes, that of the Small-Object and that of
SmallObject or SmallValueObject. The default is Loki::NoDestroy to the singleton. The rule is: The Small-Object lifetime must be greater than
insure that memory is never released before the object using that the lifetime of the singleton hosting the Small-Object. Violating this rule
memory is destroyed. Loki::SingletonWithLongevity can also insure that results in a crash on exit, because the hosting singleton tries to delete
no memory is released before the owning object is destroyed, and also the Small-Object which is then already destroyed.
insure that any memory controlled by a Small-Object Allocator is
released. The lifetime policies recommended for use with Small-Objects hosted
by a SingletonHolder template are
@par Small Singletons and Lifetime Policies - LongevityLifetime::DieAsSmallObjectParent / LongevityLifetime::DieAsSmallObjectChild
If you a singleton is derived from SmallValueObject or SmallObject, you - SingletonWithLongevity
have to use compatible lifetime policies for both the singleton and the - FollowIntoDeath (not supported by MSVC 7.1)
allocator. The 3 possible options are: - NoDestroy
- They may both be Loki::NoDestroy. Since neither is ever destroyed, the
destruction order does not matter. The default lifetime of Small-Objects is
- They may both be Loki::SingletonWithLongevity as long as the longevity LongevityLifetime::DieAsSmallObjectParent to
level for the singleton is lower than that for the allocator. This is insure that memory is not released before a object with the lifetime
why the allocator's GetLongevity function returns the highest value. LongevityLifetime::DieAsSmallObjectChild using that
- The singleton may use Loki::SingletonWithLongevity, and the allocator memory is destroyed. The LongevityLifetime::DieAsSmallObjectParent
may use Loki::NoDestroy. This is why the allocator's default policy is lifetime has the highest possible value of a SetLongevity lifetime, so
Loki::NoDestroy. you can use it in combination with your own lifetime not having also
You should *not* use Loki::NoDestroy for the singleton, and then use the highest possible value.
Loki::SingletonWithLongevity for the allocator. This causes the allocator
to be destroyed and release the memory for the singleton while the The DefaultLifetime and PhoenixSingleton policies are *not* recommended
singleton is still alive. since they can cause the allocator to be destroyed and release memory
for singletons hosting a object which inherit from either SmallObject
or SmallValueObject.
@par Lifetime usage
- LongevityLifetime: The Small-Object has
LongevityLifetime::DieAsSmallObjectParent policy and the Singleton
hosting the Small-Object has LongevityLifetime::DieAsSmallObjectChild.
The child lifetime has a hard coded SetLongevity lifetime which is
shorter than the lifetime of the parent, thus the child dies
before the parent.
- Both Small-Object and Singleton use SingletonWithLongevity policy.
The longevity level for the singleton must be lower than that for the
Small-Object. This is why the AllocatorSingleton's GetLongevity function
returns the highest value.
- FollowIntoDeath lifetime: The Small-Object has
FollowIntoDeath::With<LIFETIME>::AsMasterLiftime
policy and the Singleton has
FollowIntoDeath::AfterMaster<MASTERSINGLETON>::IsDestroyed policy,
where you could choose the LIFETIME.
- 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!
- The Small-Object has NoDestroy policy but the Singleton has
SingletonWithLongevity policy. Note: yow will get memory leaks!
You should *not* use NoDestroy for the singleton, and then use
SingletonWithLongevity for the Small-Object.
@par Examples:
- test/SmallObj/SmallSingleton.cpp
- test/Singleton/Dependencies.cpp
*/ */
template template
< <
@ -552,6 +591,9 @@ namespace Loki
// Nov. 26, 2004: re-implemented by Rich Sposato. // Nov. 26, 2004: re-implemented by Rich Sposato.
// //
// $Log$ // $Log$
// Revision 1.23 2005/11/13 16:51:22 syntheticpp
// update documentation due to the new lifetime policies
//
// Revision 1.22 2005/11/07 12:06:43 syntheticpp // Revision 1.22 2005/11/07 12:06:43 syntheticpp
// change lifetime policy DieOrder to a msvc7.1 compilable version. Make this the default lifetime for SmallObject // change lifetime policy DieOrder to a msvc7.1 compilable version. Make this the default lifetime for SmallObject
// //