QuantLib 1.6.2 Multithreading Patch for JVM/.NET

Update 23.11.2015: A modified version of the patch is now part of the official QuantLib Release 1.7.

The implementation of QuantLib’s observer pattern does not tolerate a parallel garbage collector running in a different thread. This can lead to random crashes or producing “pure virtual function calls” when using QuantLib in JVM and .NET languages (e.g. Java/Scala and C#/F#) via the SWIG interface. An original description of this problem can be found e.g. here and within the references.

With the version 1.58 and higher the boost library has extended the interface of class boost::enable_shared_from_this<T> by the method

weak_ptr<T> weak_from_this() noexcept;

which gives access to the underlying weak pointer used to implement the “shared pointer from this” functionality. This method now allows for a much cleaner and easier to install patch to make QuantLib’s observer pattern thread safe. Especially it is no longer necessary to define preprocessor defines or to edit boost files.

The implementation is backed by boost::signals2 to get the observer pattern working in a thread safe manner. The boost::signals2 library works purely based on shared_ptr. Therefore the first step is to add an Observer::Proxy class to QuantLib’s Observer, which can be registered with boost::signals2 and which forwards the update calls to the corresponding observer. In addition the class Observer is now derived from boost::enable_shared_from_this.

class Observer : public boost::enable_shared_from_this<Observer> {
          friend class Observable;
    // public interface remains untouched

    virtual ~Observer() {
        boost::lock_guard<boost::recursive_mutex> lock(mutex_);
        if (proxy_) {

            for (iterator i=observables_.begin(); 
                 i!=observables_.end(); ++i) 
    class Proxy {
        Proxy(Observer* const observer)
         : active_  (true),
           observer_(observer) {

        void update() const {
            boost::lock_guard<boost::recursive_mutex> lock(mutex_);
            if (active_) {
                const boost::weak_ptr<Observer> o
                    = observer_->weak_from_this();
                if (!o._empty()) {
                    boost::shared_ptr<Observer> obs(o.lock());
                    if (obs)
                else {

        void deactivate() {
            boost::lock_guard<boost::recursive_mutex> lock(mutex_);
            active_ = false;

        bool active_;
        mutable boost::recursive_mutex mutex_;
        Observer* const observer_;

    boost::shared_ptr<Proxy> proxy_;
    mutable boost::recursive_mutex mutex_;

    std::set<boost::shared_ptr<Observable> > observables_;
    typedef std::set<boost::shared_ptr >::iterator 

The critical path for the race condition in the original implementation is when the destructor of an observer is called while an observable triggers an update call. Now the destructor of an observer deactivates the proxy if the destructor is able to get the same mutex lock as the update method of the proxy acquires. If the proxy gets deactivated it will not forward any update calls to the observer which is about to be deleted.

If the update call manages to acquire the mutex lock then it will delay any concurrent observer destructor calls. Therefore it is safe trying to get the underlying weak pointer from the observer linked to the proxy in line 27. This weak pointer can be empty if no shared pointer has been created from the observer in the past. If a weak pointer exists then the proxy tries to get the shared pointer and calls the update methods from there. This part follows the same methodology as outlined in [1}. The rest of the implementation inherits the thread safeness from the boost signals2 library.

The patch for QuantLib 1.6.2 can be found here. It also contains Riccardo’s thread-safe singleton patch and it requires boost version 1.58 or higher.

[1] Shuo Chen, Where Destructors meet Threads


6 thoughts on “QuantLib 1.6.2 Multithreading Patch for JVM/.NET

  1. Thanks for putting together this patch. I have applied it to the currently source of QuantLib 1.6.2 and it almost built out of the box. The QuantLib core did build just fine, but I need to add a series of “Additional Include Directory” point to boost to get the C# Swig wrapper to build. After doing that it appears (fingers crossed) that some of the access violation exception I had been seeing have gone away. However, I’ve encountered another issue. It appears that I have “a memory leak” in my C# program. I unfortunately am not sure if it was there before I applied the patch, but it clearly is afterwords. Is there anything I need to do special when using the C# swig wrapper of QuantLib objects than I would normally do with C# objects? e.g. Am I supposed to be calling the Dispose method on them, or some special delete method, or forcing garbage collection?

  2. I am seeing that this really isn’t a “memory leak”. If I call
    “frequently” then the process size stays relatively stable.

  3. Thanks for testing it and the positive feedback. At a first glance I’d expect the behaviour you’ve described. To my knowledge the garbage collector only jumps in if the process image has reached a certain (big) size or if the memory becomes a rare resource in the overall system or if you call the garbage collector manually. I’ve tested the patch using my Java/Scala tests and I also haven’t seen an indicator for a memory issue. You don’t need to call the dispose message on the objects or any special delete method.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s