Hi,
I've got some crash on my QL lib when 2 threads are calling my boostrap function at the same time. Should I turn QL_ENABLE_SESSIONS to yes and define Integer sessionId(); ? In this case, how Integer sessionId(); should be defined ? I guess I need to take a parameter ( like the thread number ) Thanks Pierre |
On Fri, 2008-05-09 at 08:01 -0700, moloko wrote:
> I've got some crash on my QL lib when 2 threads are calling my boostrap > function at the same time. > > Should I turn QL_ENABLE_SESSIONS to yes and define Integer sessionId(); ? No, that won't help. But you can work around the problem in a few ways. If your yield curve is not going to be modified while the threads run (i.e., if the underlying quoted rates are not going to change) you can force bootstrap before starting the threads. You can do it by calling yieldCurve->recalculate(), or any other methods such as yieldCurve->discount(0.0). As long as the rates don't change, no further bootstrap will be performed. If your curves are going to be modified (and therefore you need the bootstrap to be performed in the threads) you can do a couple of things. The minimum-effort solution is to instantiate a different copy of the curve for each thread. This means that you'll also have to instantiate different set of rate helpers; again, one copy of each helper for each thread. The good news is that the different copies can share the same Quote instances. If you want to go the full mile, you can make the bootstrap thread-safe. I'm no expert, but you'll probably have to code the double-checked locking pattern inside LazyObject::calculate(). See the web for details. Hope this helps, Luigi -- Lubarsky's Law of Cybernetic Entomology: There is _always_ one more bug. ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
Thanks a lot for your help Luigi ... it's not gonna be a piece of cake, since
the rates are changing : I've got 2 differents curves to bootstrap at the same time. Pierre Selon Luigi Ballabio <[hidden email]>: > On Fri, 2008-05-09 at 08:01 -0700, moloko wrote: > > I've got some crash on my QL lib when 2 threads are calling my boostrap > > function at the same time. > > > > Should I turn QL_ENABLE_SESSIONS to yes and define Integer sessionId(); ? > > No, that won't help. But you can work around the problem in a few ways. > > If your yield curve is not going to be modified while the threads run > (i.e., if the underlying quoted rates are not going to change) you can > force bootstrap before starting the threads. You can do it by calling > yieldCurve->recalculate(), or any other methods such as > yieldCurve->discount(0.0). As long as the rates don't change, no further > bootstrap will be performed. > > If your curves are going to be modified (and therefore you need the > bootstrap to be performed in the threads) you can do a couple of things. > > The minimum-effort solution is to instantiate a different copy of the > curve for each thread. This means that you'll also have to instantiate > different set of rate helpers; again, one copy of each helper for each > thread. The good news is that the different copies can share the same > Quote instances. > > If you want to go the full mile, you can make the bootstrap thread-safe. > I'm no expert, but you'll probably have to code the double-checked > locking pattern inside LazyObject::calculate(). See the web for details. > > Hope this helps, > Luigi > > > -- > > Lubarsky's Law of Cybernetic Entomology: > There is _always_ one more bug. > > > ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
In reply to this post by Luigi Ballabio
Hi Luigi,
I do understand the idea to allow only to one thread the calculation of an instrument from the curve by locking LazyObject::calculate(). When I've looked about multithreading I've seen some problems that exist with the Singleton pattern. The singleton requires to lock the constructor in case of multithreading. I know that Settings::instance().evaluationDate() inherit from a Singleton. When we bootstrapp a curve, each instrument is calling instance().evaluationDate(). Do you think it could also make some problems ? I'm updating a code from QL version 0.3.4 to 0.8.1 and the LazyObject was already in use at this time ( if I look at the QL doc ). In the old version, we never had this crash with multithreading. Pierre
|
On Tue, 2008-05-13 at 06:36 -0700, moloko wrote:
> I know that Settings::instance().evaluationDate() inherit from a Singleton. > When we bootstrapp a curve, each instrument is calling > instance().evaluationDate(). Do you think it could also make some problems ? If it's just to read the evaluation date, it shouldn't be a problem. If you want to set it, you'll probably want to enable sessions so that you have a different evaluation date for each thread. Luigi -- Academic: a term of opprobrium applied to those that do their job well by those who cannot. -- Sir Ernest Gowers ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
Free forum by Nabble | Edit this page |