http://quantlib.414.s1.nabble.com/ANN-QuantLib-0-3-7-released-tp3088p3096.html
to support multithreading. Usually a Double-Checked Locking pattern is the
>
> 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
>
[hidden email]
>
https://lists.sourceforge.net/lists/listinfo/quantlib-users>