How to safely destroy an object, that is frequently accessed by two different threads?

Question

I currently ran into the Problem that an Object (Instance), that is frequently accessed by two different threads, has to be freed. For me it does not really matter which of the two threads is destructing the instance but i would prefer the one, that also creates it, although i think this does not matter at all.

So in a scenario where the thread that is supposed to destroy the object, detects that it should be deleted, and while calling the destructor, the other thread is accessing a member (function) of that object, probably some sort of runtime error will occur.

I did some research on this topic, but i could just figure out people saying: "Why deleting an Object that is still needed to exist". But in my case it should stop being needed after the piece of code that one thread is executing decides to destroy it.

I would appreciate an answer, like a hint to a nice book or article which covers this topic, but feel free to write how you would solve this problem.

Deleting isn't any different than any other synchronization issue. Use a mutex or something. — syam, Sep 26 '13 at 16:07
Not using [smart pointers](http://stackoverflow.com/questions/106508/what-is-a-smart-pointer-and-when-should-i-use-one)? — PP., Sep 26 '13 at 16:08
Use a reference-counted smart pointer to hold a reference to the object. I'd suggest shared_ptr, at least Boost's is thread-safe. — Ulrich Eckhardt, Sep 26 '13 at 16:13
@UlrichEckhardt `std::shared_ptr` (C++11) is thread-safe too. — syam, Sep 26 '13 at 16:14
so does a shared_ptr always check, if the object is still alive, when a method of it is called? — Jonas Eschmann, Sep 26 '13 at 16:27
No, that's something you have to handle yourself. But it's not difficult: use smart pointers everywhere, and when you need to pass the real pointer to some external function, you only have to ensure that you keep a smart pointer for the time the external function might try to access the real pointer. While a smart pointer exists and holds the reference, the object will not get freed. — Laszlo Valko, Sep 26 '13 at 16:55
The refcounted smart pointer typically only assert()s that it is not null. However, the pointer doesn't spontaneously become null and while one pointer still holds a reference, the object isn't destroyed either. — Ulrich Eckhardt, Sep 26 '13 at 18:22

score 1 · Accepted Answer · 2013-09-26T17:37:03.100

You would need a double indirection, to manage concurrent access to the data:

class Object {
    public;
    class Data {
        int get_value() const;
        void set_value(int);
    };

    class Guard {
        public:
        Guard(Nutex& mutex, Data* data) 
        :   data(data)
        {
            if( ! data) throw std::runtime_error("No Data");
            mutex.lock();
        }

        ~Guard() 
        {
            mutex.unlock();
        }

        Data& data() { return *m_data; }

        private:
        Data* data;
    };

    class ConstGuard {
        public:
        ConstGuard(Mutex& mutex, const Data* data) 
        :   data(data)
        {
            if( ! data) throw std::runtime_error("No Data");
            mutex.lock();
        }

        ~ConstGuard() 
        {
            mutex.unlock();
        }

        const Data& data() const { return *m_data; }

        private:
        const Data* data;
    };

    private:
    friend std::shared_ptr<Object> make_object(const Data&);
    Object(const Data& data)
    :   data(new Data(data))
    {}

    public:
    ~Object()
    {
        delete data;
    }

    /// Self destruction.
    void dispose() {
        Guard guard(get());
        delete data;
        data = 0;        
    }

    // For multiple operations use a Guard.
    Guard get() { return Guard(mutex, data); }
    ConstGuard get() const { return ConstGuard(mutex, data); }

    // For single operations you may provide convenience functions.
    int get_value() const { return ConstGuard(mutex, data).data().get_value(); }
    void set_value(int value) { Guard(mutex, data).data().set_value(value); }

    private:
    mutable Mutex mutex;
    data* data;
};

std::shared_ptr<Object> make_object(const Object::Data& data) {
    return std::make_shared<Object>(data);
}

(Note: The above code is just a sketch, I have not compiled it)

That was the long story. The short one is [20.7.2.5] shared_ptr atomic access:

Concurrent access to a shared_ptr object from multiple threads does not
introduce a data race if the access is done exclusively via the functions
in this section and the instance is passed as their first argument.

shared_ptr atomic_load(const shared_ptr* p);
void atomic_store(shared_ptr* p, shared_ptr r);
... But I am not familiar with these functions.

score 0 · Answer 2 · answered Sep 27 '13 at 08:39

The thread which should not destroy the object should hold it using a std::weak_ptr, except for the times when it is actively using it. During these times, the weak_ptr can be upgraded to a std::shared_ptr.

The thread which should destroy it now can hold on to its shared_ptr for as long as it thinks appropriate, and discard that shared_ptr afterwards. If the other thread only has a weak_ptr (not actively using it), the object will go away. if the other thread also has a shared_ptr, it holds on to the object until the operation finishes.

How to safely destroy an object, that is frequently accessed by two different threads?

2 Answers2