Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2003-09-27 16:15:17


I'm looking for design guidelines for using boost::threads along with
the singleton pattern. I'm not concerned with the threadsafe
construction of the singleton. Rather I want to return a smart pointer
to the singleton that also acts as a lock so that only one thread at a
time can access the singleton.

Something like:

struct X
     void foo() {}

struct HandleDeleter
     void operator(X*) {mut_.unlock(); owns_ = false;}

typedef boost::shared_ptr<X> Handle;

Handle singleton()
     static X x;
     static boost::mutex mut;
     return Handle(&x, HandleDeleter(mut));

void bar()
     Handle h = singleton();
     // other threads block on call to singleton
     // until h destructs
     } // singleton lock released

Several questions:

1. Does this seem like a reasonable user interface for singleton?

Clients would have the ability to hold the Handle indefinitely which
might cause thread contention, but I suspect that this will be true no
matter what.

I'm not wanting to put the lock inside of the operator-> of the handle
as the client (bar) will in general need to call several functions on X

I could make a separate get_singleton() / release_singleton() calls
(which would lock and unlock), but that seems clumsy and unsafe from an
exception safety point of view.

So assuming the answer to question 1 is yes,

2. What is the best (cleanest, most efficient, whatever) way to
implement this interface?

For the moment I'm neglecting the problem of multiple threads racing to
create any statics in singleton(). I know how to solve that problem,
and ignoring it for now simplifies the discussion.

shared_ptr<X> is used as an example smart pointer above, but I'm not yet
convinced that this is the best way to go. A variant of auto_ptr that
allowed for a customized deletion policy would probably be a better
choice. Afterall, only one instance of the handle should retain
ownership of the singleton mutex. But the smart pointer must be able to
be returned from a function (copyable), so scoped_ptr isn't viable.

Assuming the existence of some auto_ptr<X, D> (or whatever), I still
have a problem in that the custom deleter can't really traffic directly
in boost::mutex because there is no (public) interface to boost::mutex
that could lock and unlock.

I then thought that the deleter could use mutex::scoped_lock instead.
But that doesn't really work either. That gets me the lock and unlock
functions, but where or how do you store the scoped_lock? It can't be a
static of singleton, because the second thread coming in trying to lock
the static singleton (when it is already locked) will throw instead of
block. It can't be a local of singleton because it will unlock the
mutex right after you return the smart pointer. It can't be a member of
the deleter or smart pointer because the smart pointer must be copyable
(with move semantics) and scoped_lock can neither copy nor transfer
ownership of its mutex.

I finally came up with a working solution involving two mutexes, two
scoped_locks, and one condition:

  Handle singleton()
     static mutex mut;
     static mutex mut2;
     static scoped_lock lk(mut, false);
     static condition c;

     static X x;

     scoped_lock guard(mut2);
     while (lk)
     return Handle(&x, HandleDeleter(lk, c));

And when the Handle destructs, the HandleDeleter both unlocks lk, and
calls notify_one on the condition.

The HandleDeleter is copyable because it refers back to the static mutex
and condition of singleton instead of copying them internally. And
Handle is an auto_ptr knock off that takes a deleter.

Is it just me, or is this much harder (and more expensive) than it needs
to be? Am I missing some simpler, lighter weight solution?

Better ideas?


Boost list run by bdawes at, gregod at, cpdaniel at, john at