|
From: W. A. C. <ant...@gm...> - 2012-04-17 22:20:13
|
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
|