RE: Re: [Quantlib-dev] Quantlib within a multithreaded architecture.

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

Hi,

Yep this is a tricky one!!

The threading idea is an idea, but for most people, you need to code this
extra threading logic
carefully outside of QuantLib. I was under the impression that 'thread-local
storage' was a critical resource, if you build too many objects each needing
their own resources... well I haven't tested it myself, but maybe Ashish
Kulkarni can comment on this.

I seem to remember that there was an explicit Today's Date parameter
associated with the Yieldcurve object within QuantLib 0.3.7. There you had
the setTermStructure()  function within the RateHelpers and the fixing()
function from the Xibor class refering to this YieldCurve Today's date for
reference.

I liked this because the Today's Date parameter did not touch many
interfaces, within QuantLib 0.3.7, all pricing functions refered to this
YieldCurve->TodaysDate for reference somewhere in the bowels of their
implementation. The good news here though was that the TodaysDate parameter
was associated with the YieldCurve object and not passed as an explicit
parameter.

Thus you had a local Today's Date associated with the yieldCurve. Need to
compute Theta? No problem, shift the date within the YieldCurve. No side
effects on other functions or fancy threading.

Why did this TodaysDate parameter vanish from earlier versions of QuantLib?

Thanks for checking-in the BondHelper class (with your modifications).

Best Regards,
Toy out.

>From: Luigi Ballabio <[hidden email]>
>To: Toyin Akin <[hidden email]>
>CC: [hidden email]
>Subject: [Quantlib-users] Re: [Quantlib-dev] Quantlib within a
>multithreaded architecture.
>Date: Fri, 09 Sep 2005 09:47:46 +0000
>
>
>On 08/02/2005 06:02:44 AM, Toyin Akin wrote:
>>I've been working with QuantLib the last serveral months looking at  the
>>possibility of producing a commercial multithreaded .NET engine.
>>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.
>
>Toyin,
> apologies for the delay. I still have some catch-up to do after  my
>vacations...
>
>As to the multithreading issue: man, is this a tricky one.
>
>It seems to me that adding an explicit parameter---be it the evaluation  
>date, a thread or session ID, or some other kind of settings  
>object---would percolate through and pollute too many interfaces. It  
>should be added as a parameter to Instrument::NPV(),  
>Instrument::calculate(), YieldTermStructure::whatever(),  Xibor::fixing(),
>CashFlow::amount()... it is painful just to think of  it. I would very like
>prefer that Settings remained globally accessible.
>
>But on the other hand, we should be able to have different threads get  
>hold of different Settings instances, otherwise they will either have  to
>be serialized (defeating the very purpose of threads) or step on  each
>other's toes. A few months ago, Ashish Kulkarni mentioned  thread-local
>storage; as far as I can see, it seems an interesting  
>possibility---although I'm not sure that we can code it in the library  
>directly and in a portable way. Moreover, the library might be called  from
>different languages, and they might provide their own thread  
>implementation.
>
>At this time, I'm inclined to turn the Singleton class into a Multiton  and
>add a hook so that different instances can be requested behind the  
>curtains. I'm thinking of an implementation along the lines of:
>
>#if defined(QL_ALLOW_SESSIONS)
>Integer sessionId();   // note: declared, but not defined in
>                        // the library itself
>#endif
>
>T& Singleton<T>::instance() const {
>     static std::map<Integer, boost::shared_ptr<T> > instances_;
>     #if defined(QL_ALLOW_SESSIONS)
>     Integer id = sessionId();
>     #else
>     Integer id = 0;
>     #endif
>     boost::shared_ptr<T>& instance = instances_[id];
>     if (!instance)
>         instances_[id] = instance = boost::shared_ptr<T>(new T);
>     return *instance;
>}
>
>When QL_ALLOW_SESSIONS is undefined (which would be the default) the  
>singleton will work as it does now. However, users wanting to have  
>different instances will have the possibility to #define it. In this  case,
>they'll have to define their own implementation of sessionId(),  which will
>return a different id for different threads, and link it  with the library.
>This will give them the possibility to implement  sessionId() in the most
>convenient way, e.g., using thread-local  storage in a C++ application,
>calling back to Python or Ruby to  interrogate their thread manager if the
>library is exported to such  languages, or doing whatever is necessary in
>.NET to get a thread id.
>
>Thoughts?
>
>Later,
> Luigi
>
>
>----------------------------------------
>
>Quote me as saying I was misquoted.
>-- Groucho Marx
>
>
>
>-------------------------------------------------------
>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