Local static initialization in singleton.hpp

[W. Anthony Calore]

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.

Thanks,

William

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Luigi Ballabio]

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
<[hidden email]> 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.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev