As I mentioned before, using TLS for singletons is a rather simple way
of solving the problem although making that code portable is rather
difficult.
Actually, what is missing is the concept of a calculation "session". All
these singletons are per-session (eval date, exchange rates, benchmark
history, etc), The current approach means that there is effectively only
one shared session. Using TLS would mean that there is one session per
thread. An ideal scenario would be that you could create multiple
sessions per thread, but then you'd need to pass the session object to
every class (like the evaluation date was being done before being
refactored).
Having such a session object would be very useful for using QuantLib in
"what-if" scenarios: however, having one explicitly would mean that
objects created in one session wouldn't be valid in another. That's
another can of worms... Personally, I prefer the session-per-thread
concept and TLS rather neatly solves the problem of passing the session
around ;-)
Daniele De Francesco wrote:
> I am a bit concerned about the evaluation date in a threaded environment
>
> Right now it's something that we get from a Singleton class. That means that
> if I have two threads that run in parallel and each of them wants to do some
> pricing at different points in time, I will run into serious problems.
>
> Can anyone think of a solution or at least a workaround for this?
> I know that as of version 0.3.8 I can still build a term structure that
> doesn't rely on the evaluationDate() but it's been deprecated so it won't be
> there in the future.
>
> If anyone can think of some way to get around this (or if I'm wrong about
> the whole thing), please let me know!
> _Daniele
>
>
>
>
>
> -----Original Message-----
> From: Ashish Kulkarni [mailto:[hidden email]]
> Sent: Wednesday, April 27, 2005 12:22 AM
> To: zheng wang
> Cc: [hidden email]
> Subject: Re: [Quantlib-users] Help in running QuantLib in multithreaded
> process on windows
>
>
> You will have to make the Singleton class template thread-safe. The
> simplest way is to put the data in Thread-Local Storage. Using a mutex
> is not really ideal, as you'll run into performance issues very quickly.
>
> Also, check that you are not writing to shared STL containers in
> multiple threads, as the STL itself is not guarenteed to be thread-safe.
>
> zheng wang wrote:
>
>>we would like to run Swapvaluation.cpp in a multithreaded environment;
>>we modified the code by wrapping all the functionality in main() of the
>>aforementioned file into a new function abc() and created two threads in
>>main() to call abc(). It always crashes. I wonder if we did something
>>wrong or QuantLib is not thread-safe at all. Your help would be greatly
>>appreciated.
>>Thanks.
>
>
> Greetings!
> ICICI Infotech is now 3i Infotech.
> The e-mail addresses of the company's employees have been changed to
> @3i-infotech.com. You are requested to take note of this new
> e-mail ID and make use of the same in future
> "This e-mail message may contain confidential, proprietary or legally
> privileged information. It should not be used by anyone who is not the
> original intended recipient. If you have erroneously received this message,
> please delete it immediately and notify the sender. The recipient
> acknowledges that 3i Infotech or its subsidiaries and associated companies,
> (collectively "3i Infotech"), are unable to exercise control or ensure or
> guarantee the integrity of/over the contents of the information contained in
> e-mail transmissions and further acknowledges that any views expressed in
> this message are those of the individual sender and no binding nature of the
> message shall be implied or assumed unless the sender does so expressly with
> due authority of 3i Infotech. Before opening any attachments please check
> them for viruses and defects."
>
| Greetings!
ICICI Infotech
is now 3i Infotech.
The e-mail addresses
of the company's employees have been changed to <existing name>@3i-infotech.com.
You are requested to take note of this new e-mail ID and make use of the
same in future
"This e-mail
message may contain confidential, proprietary or legally privileged information.
It should not be used by anyone who is not the original intended recipient.
If you have erroneously received this message, please delete it immediately
and notify the sender. The recipient acknowledges that 3i Infotech or
its subsidiaries and associated companies, (collectively "3i Infotech"),
are unable to exercise control or ensure or guarantee the integrity of/over
the contents of the information contained in e-mail transmissions and
further acknowledges that any views expressed in this message are those
of the individual sender and no binding nature of the message shall be
implied or assumed unless the sender does so expressly with due authority
of 3i Infotech. Before opening any attachments please check them for viruses
and defects."
|
Locked
