[Quantlib-dev] Quantlib within a multithreaded architecture.

[Toyin A. <toy...@ho...>]

Hi All,

As some of you may have noticed, I have pulled my CapeTools QuantLib Web 
Site. I am in the process of producing a new version which uses the current 
QuantLib C++ library, complete with user documentation.

I've been working with QuantLib the last serveral months looking at the 
possibility of producing
a commercial multithreaded .NET engine. Basically another layer on top on 
QuantLib C++
itself, rather than a total rewrite like I did before.

The previous approach was fine and educational in terms of how QuantLib is 
structured, but it was a pain in the neck to keep it up to date with the 
pace of development that the QuantLib guys were generating.

With a C# wrapper on top of the C++ framework in which the wrapper itself is 
enabled for multi-threaded use as well as other wrappers I am developing for 
.NET web services,  .NET remoting
and a full Excel implementation (1000+ Excel functions thus far...), I can 
concentrate on these sexy features without the full re-write of QuantLib in 
.NET.

The main problem I have found which would prevent this from working within a 
multi-threaded environment (Wrapper on top of the C++ layer), are those of 
the 3 Singleton classes.

ExchangeRateManager, IndexManager and Settings.

Now that first 2 are not that difficult to overcome as they are used in a 
relatively small portion of the QuantLib codebase. The latter class, 
Settings, is the problem.

This is used by almost every pricing, YieldCurve class.

Thus if you have the scenario, even within a multithreaded C++ application, 
where User A creates a YieldCurve (ie - the PiecewiseFlatForward class, 
using the constructor that takes a reference date) with reference date 
2/MAR/2005 and User B creates a similar curve with reference date 2/JUN/2006 
and both submit the request to a server, the server may strip the curves 
correctly, but when the 2 users want to calculate a swap price/rate, you now 
have a problem.

The Settings::instance.evaluationDate() function is called to retrieve the 
calculation date. But User A wants his at 2/MAR/2005  and UserB at 
2/JUN/2006.

You could override the evaluationDate() within the global Settings class in 
each case, but then you open up a can of worms because while UserA has set 
the Settings::instance.evalutionDate() (either externally, which is not a 
good idea, because he is manipulating a global variable) or the programmer 
in code within the wrapper swap() function, UserB may come in a split second 
later into the same function and change the value again, thus invalidating 
the results that UserA will generate.

You could add some sort of mutex within the Wrapper Swap() function to block 
the call until UserA has finished (The Swap function will manipulate the 
evaluationDate() function), but the locations within the QuantLib library 
where Settings::instance.evalutionDate()
are called are too numerous. Thus you would have to write some sort of 
critical section, mutex for the whole library or make the quantlib library 
single-threaded in use.

This problem is actually not only tied to YieldCurves, almost every pricing 
function is affected by this too. Thus anyone who wants to manipulate the 
evaluationDate() function within a multithreaded application is asking for 
trouble.

However, maybe you guys have a solution for this, or someone has encounted 
this and has a solution.

I had the chance on working on a similar library within a commercial bank 
for 6 years implementing everything from YieldCurves to the pricing and risk 
management of portfolios of CapFloors, Swaps and Swaptions. Also the pricing 
of exotic structured deals and I can tell you, the quantLib infrastructure, 
apart from CMS Swaps and portfolio and risk management features, contains 
nearly everything else that this library had. In addition, you have all the 
exotic option calculation as well.

By the way, apart from this singleton issue, I believe that this is the best 
library that all financial engineers should look at, if they want to get 
their C++ financial skills to up speed in a relatively short space of time.


Best Regards,
Toyin Akin.
CapeTools.