Posted by
W. Anthony Calore on
Apr 17, 2012; 10:20pm
URL: http://quantlib.414.s1.nabble.com/Local-static-initialization-in-singleton-hpp-tp11821.html
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