Re: [boost] [flyweight][#3658] Dependency on static initialization/destruction order

Subject: Re: [boost] [flyweight][#3658] Dependency on static initialization/destruction order
From: Joaquin M Lopez Munoz (joaquin_at_[hidden])
Date: 2009-11-28 10:49:46

Andrey Semashev <andrey.semashev <at> gmail.com> writes:

> 
> Hi,
> 
> I've created the ticket #3658 [1] on the flyweights library. The ticket 
> is about Boost.Flyweight depending on the static 
> initialization/destruction order, which can lead to application crashes 
> in some cases.
> 
> The library does provide certain tools to work around the problem [2], 
> but these tools are only usable in the most obvious cases and do not 
> solve the problem in its root.

Hi Andrey,

Singletons (which is what Boost.Flyweight holder finally boil
down to, see http://tinyurl.com/y996eqr ) are notoriously hard to
get right, as explained for instance in Alexandrescu's "Modern
C++ Design", and in the end one has to settle for some compromise.
Boost.Flyweight uses holders in such a way that it guarantees
initialization before main() begins, which for the most part avoids
problems with lazy initialization in multithreaded environments.

> What I have proposed in the ticket is to implement reference counting in 
> the flyweights, so that the flyweight value is only destroyed when no 
> flyweight handles refer to it. AFAIK, Boost.Flyweight already has 
> reference counting, so the work is only to shift value owning from the 
> holder to the flyweights.

I'm not sure what's the exact proposal you have. Take into
account that refcounts applies to flyweight values, while
holders (as defined in Boost.Flyweight) deal with initializing/destroying
the flyweight value *factory*, that is, the object that holds the
values.

This is basically the implementation of static_holder, the default
holder for Boost.Flyweight:

template<typename C>
struct static_holder_class
{
  static C& get()
  {
    static C c;
    return c;
  }
};

Would you mind sketching what replacement for static_holder_class
you have in mind?

Thank you,

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

PS: There's an additional approach that can solve the issue
at hand, namely implementing a holder that never destroys
the held object, but this is something I'd like to discuss
with you after your original refcount proposal is dealt with.