Re: [Quantlib-dev] Local static initialization in singleton.hpp

[Luigi B. <lui...@gm...>]

Hi William,
    apologies for the delay.  We've had another contribution recently
on the singleton issue, that applies the same patch and also addresses
the problem of managing the session-id function at runtime.  The diffs
are at <https://github.com/mortoray/quantlib/commit/dbf6b23429b21cccb0982d6f3e5c13f5860842e1>;
it would be great if you (and anyone interested) could have a look and
comment.

Thanks,
    Luigi


On Wed, Apr 18, 2012 at 12:20 AM, W. Anthony Calore
<ant...@gm...> wrote:
> Hi all,
>
> I was looking at the thread-safety bug identified in singleton.hpp. To fix
> this bug I thought to throw a lock on a class static boost::mutex into the
> template class function singleton<t>::instance() to serialize access to
> instances_
>
> +      boost::mutex::scoped_lock lock(mutex_);
>         boost::shared_ptr<T>& instance = instances_[id];
>
> Since instances_ is a local static, it's probably important to point out
> that its initialization is not necessarily thread-safe depending on the
> compiler in use. I pretty much ignored that problem entirely.
>
> Also, to use boost/thread.hpp, the boost/bind.hpp header gets included,
> which adds additional placeholders to the global namespace.
>
> The effect this would have is that using the inclusion of boost/bind.hpp
> requires you to add qualifiers to the
> /ql/pricingengines/vanilla/analytichestonengine.cpp such that every
> reference to the placeholder _1 becomes boost::lambda::_1  . Otherwise
> you'll get compile-time errors for ambiguous reference
>
> It turns out that this is the only place where that caused a naming
> collision.
>
> This would be kind of a weird change and I have never submitted any patches
> for this project so I thought I'd ask the list for its thoughts.