Bootsrapping and multithreading

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Bootsrapping and multithreading

moloko
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
Reply | Threaded
Open this post in threaded view
|

Re: Bootsrapping and multithreading

Luigi Ballabio
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
Reply | Threaded
Open this post in threaded view
|

Re: Bootsrapping and multithreading

moloko
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
Reply | Threaded
Open this post in threaded view
|

Re: Bootsrapping and multithreading

moloko
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

Luigi Ballabio wrote
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
QuantLib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/quantlib-users
Reply | Threaded
Open this post in threaded view
|

Re: Bootsrapping and multithreading

Luigi Ballabio
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