Re: [Quantlib-users] Quantlib within a multithreaded architecture.

[Gianni P. <gpi...@ho...>]

IMHO If you haven't already done it I think you should customize the 
singleton class
to support multithreading. Usually a Double-Checked Locking pattern is the
right choice but you have to pay attention to the hardware architecture 
also.
As far as Settings::instance.evalutionDate() is concerned a simple idea is 
to use the
thread id as the key of an associative map and than overloading the 
evaluationDate appropriately
(using the key as a function argument and returning/set the right date).
I hope it helps.

ciao Gianni.

----- Original Message ----- 
From: "Toyin Akin" <toy...@ho...>
To: <na...@qu...>; <qua...@li...>; 
<qua...@li...>; 
<qua...@li...>
Sent: Tuesday, August 02, 2005 6:02 AM
Subject: [Quantlib-users] Quantlib within a multithreaded architecture.


>
> 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.
>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Quantlib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>