Well, Singleton returns an instance ... perhaps we could mix the two
solutions at this level ...
What about changing a little the default ?
Instead of defaulting to a single session per application, default to a
single session per thread (via TSS).
When the user registers a sessionId function (via setSessionIdFunc),
switch to lock+map.
If you want, I'll try to concoct an implementation along these lines.
I am a bit uncomfortable, however, with a sessionId-based solution.
IMO is inherently fragile: one must ensure than no one will modify the
same session from different threads.
So the application must be single-threaded, or use some other method to
avoid trashing the singletons.
This even when Singleton is using locks, as in Mortoray implementation.
A lock in this case protects only the mapping id-singleton, not the
singleton data.
Consider this example, with a default sessionId(), i.e. one returning
always 0:
thread 1 calls
Settings::instance().evaluationDate()= Date(1, Jan, 2012);
meanwhile thread 2 calls
Settings::instance().evaluationDate()= Date(15, Jan, 2012);
Settings::instance() can be accessed by one thread at time, but
afterward both threads have a reference to the same instance, so no one
knows really what value will have the evaluation date.
To avoid this race you have to lock the entire sequence, or associate a
session to a single thread, perhaps via thread storage :).
Riccardo
-------- Original Message --------
Subject: Re: [Quantlib-dev] thread safe session handling via TSS
From: Luigi Ballabio <
[hidden email]>
To: Riccardo Ghetta <
[hidden email]>
CC: "
[hidden email]"
<
[hidden email]>, Ferdinando Ametrano
<
[hidden email]>
Date: Monday, November 26, 2012 16:21:14
> It might be reasonable. But as mortoray argued, one might want to
> switch between the two possibilities without recompiling; especially
> those that don't compile the library and get it packaged from a Linux
> distribution. If we provide such a switch, linking libboost_thread
> would be required anyway. What do you think?
>
> A future possibility would be to rework mortoray's patch so that the
> pluggable function returns the instance directly instead of an integer
> id; in such an implementation, your technique would just provide a
> particular function. However, that's not backward compatible...
>
> Luigi
>
>
> On Tue, Oct 23, 2012 at 3:43 PM, Riccardo Ghetta <
[hidden email]> wrote:
>> Not directly, no.
>> I've looked at mortoray patch. Unfortunately that scheme is not compatible
>> with thread storage; having a per-thread instance makes all the
>> sessionId/sessionIdFunc machinery useless. In a way, is implicitly handled.
>> Likewise for the instances_ map.
>>
>> On the other hand, perhaps I can rework the tss patch to avoid including
>> boost thread headers in singleton.hpp, if we don't want to force quantlib
>> users to compile with boost:thread.
>> That should preserve the main qualities of the above patch, i.e. being
>> thread-safe and not requiring libboost_thread, plus the added safety,
>> simplicity and performance of tss.
>>
>> it might be a reasonable solution ?
>> Ciao,
>>
>> R
>>
>>
>> -------- Original Message --------
>> Subject: Re: [Quantlib-dev] thread safe session handling via TSS
>> From: Luigi Ballabio <
[hidden email]>
>> To: Riccardo Ghetta <
[hidden email]>
>> CC:
[hidden email], Ferdinando Ametrano
>> <
[hidden email]>
>> Date: Tuesday, October 23, 2012 12:10:59
>>> Riccardo,
>>>
>>> I just had a look at your patch. Is there any chance that it can
>>> be made to work together with the pending patch at
>>>
>>> <
https://github.com/mortoray/quantlib/commit/dbf6b23429b21cccb0982d6f3e5c13f5860842e1>?
>>> (Yes, we have stuff all over the place and it's not easy to find it.
>>> Our bad.)
>>>
>>> About the contributor agreement: in the past we used something like
>>> the document I'm attaching. You can scan the signed document and send
>>> it to me and Ferdinando (whose address is in cc).
>>>
>>> Thanks,
>>> Luigi
>>>
>>>
>>> On Fri, Oct 19, 2012 at 3:22 PM, Riccardo Ghetta <
[hidden email]> wrote:
>>>> Hi,
>>>> I've just posted a patch to enable thread safe session handling. It
>>>> should also solve bug 3441748.
>>>> The company I work for, Thema Consulting SA (www.themaconsulting.ch),
>>>> uses QuantLib in its MasterFinance product and has other patches we like
>>>> to contribute back (as soon they're cleared by management/legal).
>>>>
>>>> BTW, is the contributor agreement needed ? Where should be sent ?
>>>> I searched the mailing list, but without luck.
>>>>
>>>> Ciao,
>>>> Riccardo Ghetta
>>>> Thema Consulting SA
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>>
http://p.sf.net/sfu/appdyn_sfd2d_oct>>>> _______________________________________________
>>>> QuantLib-dev mailing list
>>>>
[hidden email]
>>>>
https://lists.sourceforge.net/lists/listinfo/quantlib-dev>>
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Locked
disclaimer.rtf (18K)