Quantlib within a multithreaded architecture.

Posted by Toyin Akin on
URL: http://quantlib.414.s1.nabble.com/ANN-QuantLib-0-3-7-released-tp3088p3089.html

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.