[boost] Re: Singleton

From: Dave Handley (dave.handley_at_[hidden])
Date: 2005-01-11 04:56:48

Jason Hise wrote:

> 
> I'm actually working on the longevity policy now.  I'm trying to do it
> without using atexit, and instead using a hidden internal singleton that
> manages the lifetimes of the others.  It should be interesting.
> 

Good idea - I look forward to seeing the results.

> > 3)    Possibly include the ability to turn off phoenix singletons in
> > the dependency lifetime policy.
>

>From what I remember, Loki throws an exception.
 
> This leads to an interesting question: what should happen if a class
> tries to get access to a destroyed singleton?  I would personally think
> that it would always be desirable to have it come back, but then this is
> just my opinion and probably falls into the same category as me
> preferring dependencies to longevities.  Which leads me to wonder if
> OnDeadReference should be an additional policy of the lifetime policy
> itself.

Let me give you an example where you may want a dead reference
exception rather than a phoenix singleton.  Let's say you have a
singleton that performs a client access to a database.  When the
client is started up, it asks for a username and password, and logs
the client access in the database.  You definitely would not want this
to go through a phoenix singleton because of the side-affects.  Making
OnDeadReference a policy of the lifetime policy probably makes a lot
of sense, since you have essentially implemented the phoenix singleton
as an extra to the lifetime policy in the dependency model.

> 
> > 4)    Threading.
> 
> I'm going to need help with this one.  My current thought is to provide
> a lock policy.  The lock would be required to provide locking upon
> creation and unlocking upon destruction, and then all the other policies
> of the singleton would inherit this policy and could simply insert lock
> objects wherever they are needed.  The default single threaded lock
> would just be an empty class.  Unfortunately I have no experience with
> how threading actually works, and I am worried that the two threads
> would just end up creating two different locks and neither would block
> the other.  If I am not on the right track, please point me in the right
> direction.
> 

The problem with threading is that it is up to the OS to define the
threading system.  This means that threading is usually non-portable. 
I would recommend therefore looking at boost.threads which provides a
portable threading system.  Loki uses a very simple system of
policies.  The 3 policies implemented are a SingleThreadPolicy,
ObjectLevelLocking and ClassLevelLocking.  The object level locking
basically locks a mutex that is defined on an object level, whereas
the class level locks a mutex for all objects of that class.  The
implementation is via CRTP again.  There are some added bits in Loki
like the volatile type is typedefed so you can get the volatile
qualifier right (you shouldn't use volatile in single-threaded because
it can disable compiler optimisations).  It does this using

template <class Host>
class ObjectLevelLocking
{
    typedef volatile Host VolatileType;
};

whereas the SingleThreaded version just does:

typedef Host VolatileType;

The locking itself works with an inner class called Lock that you
construct on the stack whenever you need to lock.  On construction it
locks the mutex and on destruction it frees it.

I've not personally used the boost threads library so I can't help you
on that one.

Dave Handley