Re: [boost] Thread-safe singleton (was [FSM] Review library version update)

From: Andrey Semashev (andysem_at_[hidden])
Date: 2007-02-06 13:09:14

Hello Sohail,

Tuesday, February 6, 2007, 1:34:50 AM, you wrote:

> Hi Andrey,

>> Tuesday, February 6, 2007, 1:08:25 AM, you wrote:
>> 
>> > Is there interest in having a boost singleton? A preliminary
>> > implementation of it could use boost::once. Then all lazy
>> > initializations would happen through that interface.
>> 
>> > Just a thought.
>> 
>> I think a generic implementation of a thread-safe singleton is a nice
>> idea. I encounter this problem quite often. Although, once-based
>> implementation doesn't suit me very well in this case.

> What kind of solutions have you come up with for lazily initializing
> singletons in a thread-safe manner?

In most cases I tried not to create the singleton lazily but
initialize it as soon as possible. The perfect time is on executable
module load which, AFAIK, is always done in single thread on
platforms I have faced yet. Such approach was quite sufficient for me
since it solves the key problem of the singleton creation. And the
created singleton may be not fully initialized at first, i.e. it may
not acquire significant system resources on construction but may do so
on first requests to it. Such requests are easy to synchronize since
the singleton with a mutex already exists.

Maybe a similar approach in a generic implementation of a lazy
singleton worth considering too. I mean, on module load the
implementation may safely construct a mutex and a null reference to
a yet non-exiting singleton instance (see Alexandrescu's
implementation with dead reference detection). This would let you to
synchronize later when the instance is requested first time and needs
to be created. And the very same mutex may be used by the singleton
later for its own needs.

The problem is that I guess not every compiler/platform would let you
to hook into the module load sequence. For those configurations we
might fall back to once-based implementation.

> What are your reasons for not
> preferring a boost::once implementation? I can only think of boost::once
> based or platform specific, which scares me, to be frank!

In the Boost.FSM lib boost::call_once is not very desirable because
that lib is intended to be light. It may even be used without
threading at all (and in fact, this is expected to be the major domain
of use). So I cannot force users to build Boost.Thread just to support
the internals of the header-only library.

The same disadvantage would be in case of the generic singleton
implementation. I believe that such implementation should provide a
way to create singletons without requiring building any libraries in
single-thread and even in multi-thread environment, where possible.

Maybe if there was some lightweght_call_once somewhere in Boost the
problem would be solved.

> The solution to the problem seems to be a function of hardware and OS
> primitives which (I thought) pthread_once/family solve as nicely as
> you'd want.

Pthreads are quite widespread but not ultimate. At least win32
threading needs to be supported too.

> Personally, I'm fairly new to the whole multi-proc scene so I'd really
> appreciate some enlightenment!

I'm no expert too. Let's hope that someone who really knows the field
is reading this.

-- 
Best regards,
 Andrey                            mailto:andysem_at_[hidden]