是否使用类包装器对符合C ++ 11的对象进行线程安全访问？

Question

Can I use this class-wrapper for thread-safe access to the object, and desired behavior conforms to C++11?

Main accent to the strings:

T* operator->() {

and

T& operator*() {

Note, I know that here optimal to use std::atomic<> for the integer(int), but in this code instead of int we can use any other object.

Version 2.0 by using execute-around pointer idiom :

#include<thread>
#include<mutex>
#include<memory>
#include<iostream>
#include<vector>

template<typename T>
class safe_obj {
    T obj;
    mutable std::mutex mtx;
    safe_obj(safe_obj<T> &) {}
    safe_obj<T>& operator=(safe_obj<T> &) {}

    class T_exclusive_lock {
         std::unique_lock<std::mutex> xlock;
    public:
         T*const self;
         T_exclusive_lock(T * const s, std::mutex& _mtx)
             :self(s), xlock(_mtx) {}

        T* operator -> () const {return self;}
        operator T&()  {return *self;}

        friend std::ostream& operator << (std::ostream &stream, T_exclusive_lock &obj) {
            stream << obj;
            return stream;
        }
    };

public:
    template<typename  Types>
    safe_obj(Types  args) : obj(args ) 
    { }

    T_exclusive_lock operator->() {
        return T_exclusive_lock(&obj, mtx);
    }    

    T_exclusive_lock* operator*() {
        return &T_exclusive_lock(&obj, mtx);
    }       
};

int main() {
    safe_obj<std::shared_ptr<int> > safe_int( std::make_shared<int>(10) );   

    auto lambda = [&safe_int]() {
        std::cout << safe_int->use_count() << std::endl;    // is that thread-safe? 
        std::cout << *safe_int << std::endl;    // is that thread-safe? 
        std::cout << *safe_int->get() << std::endl;    // is that thread-safe? 
    };

    std::vector<std::thread> thr_grp;
    for(size_t i = 0; i < 10; ++i) thr_grp.emplace_back(std::thread(lambda));
    for(auto &i : thr_grp) i.join();

    int b; std::cin >> b;
    return 0;
}

Answer 1

The original code you provided didn't guarantee any thread-safety. Your std::unique_lock s unlock the mutex as soon as they get out of scope, which is prior to the use of the object you wanted to protect.

To achieve the desired result, you would need to declare another templated class (eg locked_obj<T> ) which would represent the object in a locked state (by having a unique_lock on the safe_obj 's mutex) and return such an object from the overloaded operators. Such an object would be a temporary one and allow you to manipulate the guarded object during the lifetime of locked_obj . As temporary objects live until the end of current statement, use of such safe_obj s would be mostly transparent.

This technique is an application of execute-around pointer idiom.

Answer 2

No, that's not thread-safe. By the time the accessor functions return, the mutex has been unlocked, so access to the object is not synchronised.

One approach is to overload assignment and conversion operators:

safe_obj & operator=(T const &t) {
    std::unique_lock<std::mutex> lock(mtx);
    obj = t;
    return *this;
}

operator T() {
    std::unique_lock<std::mutex> lock(mtx);
    return obj;
}

but this might get tedious if you want to provide all the compound assignment operators, and the conversion operator won't work if the object is not copyable.

Another approach would be to return an accessor object containing a unique_lock , which keeps the mutex locked as long as you have access to the object.

Answer 3

Locking individual functions or locking accesses to an individual object does not guarantee thread safety; depending on the program, many operations require multiple function calls on the same object without interruption or operations on multiple objects without interruption. Thread safety has to be designed into an application; there are no library hacks that will make an application that isn't properly designed thread-safe.