Thread aware calculation of LazyObject about qlnet

[tournierjc]

I think your workaround will work for your test case but it's look to me more like an ugly fix.

It's the Settings and Observable pattern that should be threadsafe and it is your program who needs to be aware of the objects you share between threads.

[channell]

I first came across Quantlib in the comments of an Investment Banks Quant Library “copied from the original quantlib”.. the most common reason to copy rather that use Quantlib is the mistake introducing Observable to assist the StatPro pricing service: a hack for to present price/yield functions independently without the need to pass a previously calculated value into a “price given yield” or “yield given price” function.

A proper quant library should be fully functional (with no side effects), but that will require a major re-write. The suggestion of spinlock is indeed a work-around for a pattern that should not be there.

I added spinlock_ in addition to bootstrapping_ (the fix to concurrency issue I was seeing) in order to avoid the side effect of duplicate observer notifications and co-mutation if more than one thread performs the same calculation (numeric consistency is questionable writing doubles on a 32-bit computer without interlocked exchange)

Given the marginal cost of plugging this problem, it is worth doing

[amaggiulli]

Hey @channell , thx for your PR , I agree with you about the uneeded pattern , what about working togheter to completly remove it from the library ? In the QLNet development we did several hack to avoid this problem with the only result to make the code ugly and difficult to read and without fixing the issue. Let me know if you have any idea on how to proceed.

[tournierjc]

Hello @channell, @amaggiulli,

I've started a fork of QLNet moving to Visual Studio Code, .NET Core 3.1 and xUnit. You can find it here : https://github.com/OpenDerivatives/QLCore

I've removed the Observer & Observable pattern and so far it seems to work (only one test is not working but it is not working on original QLNet either and has been removed from tests), and some issues can still happen with ExchangeRateManager, but I'm looking into it.

There is still a lot to do on this fork. @amaggiulli do not hesitate to remove this message if it not appropriate and please let me know if the fork do not respect the original license.

[oliviermilla]

@tournierjc why not do that here as a major version? I mean, It's QLNet + refactoring + some more from QuantLib right?