Hi Martin,

   After a first glance it seems strange that you are only requesting the lock (sync_init) in get_instance(), which seems to be ok anyway (after quite a lot of shared_ptr/weak_ptr internals). Now I wonder whether the busy wait is needed or the combination of a mutex and a condition variable could be better, waking the waiting thread just when destruction of the object completes.

   Also I am not sure of the necessity of having both a start_construction() and finish_construction() that require two mutex acquisitions:
// Using boost::condition:
struct dynamic_singleton::impl : private boost::noncopyable
{  
    impl() {}
    ~impl() {}
    static void start_construction()
    {  
        boost::recursive_mutex::scoped_lock lock( sync_ );
        while ( the_object_exists ) {
            cond_.wait( lock );
        }
        the_object_exists = true;
    }
    static void finish_destruction()
    {  
        boost::recursive_mutex::scoped_lock lock( sync_ );
        the_object_exists = false;
        cond_.notify_one();
    }
    typedef boost::weak_ptr<dynamic_singleton> internal_shared_t;
    static internal_shared_t the_object;

    static boost::recursive_mutex sync_init;
    static boost::recursive_mutex sync_;    // moved from atomic_bool
    static bool the_object_exists;  // plain bool, synch'ed with sync_
    static boost::condition cond_;
};
dynamic_singleton::impl::internal_shared_t dynamic_singleton::impl::the_object;
boost::recursive_mutex dynamic_singleton::impl::sync_init;
boost::recursive_mutex dynamic_singleton::impl::sync_;
bool dynamic_singleton::impl::the_object_exists = false;
boost::condition dynamic_singleton::impl::cond_;

   Together with the rest of the code. As get_instance() warrants that there is at most one process trying to create the object, and all possibly deleting threads have already gone by (after the while loop in start_construction() ) changing the bool here or later is just the same.

   One other comment, I would mark both constructor and destructors for impl as private, since all methods and data are static there is no point in constructing objects of this class. This requires modifying dynamic_singleton class to remove the pimpl attribute.

   David