以线程安全的方式与外界共享数据成员

Question

我真的很感激有关此事的一些建议。

例如

class Foo
{
    TData data;
public:
    TData *getData() { return &data; } // How can we do this in a thread safe manner ?
};

，所以我想要一种机制来使 getData() 线程安全。我提出了自己的解决方案，其中涉及将数据成员打包在以下模板类中，并使用用于同步对其访问的互斥体。你怎么认为 ？可能出现什么问题？

class locked_object : boost::noncopyable
{
    T *object;
    TLockable *lock;
    bool locked;

public:
    locked_object(T *_object, TLockable *_lock) : object(_object), lock(_lock), locked(true)
    {
        lock->lock();
    }

    ~locked_object()
    {
        lock->unlock();
    }

    T *get()
    {
        _ASSERT(locked);
        if (!locked)
            throw new std::exception("Synchronization error ! Object lock is already released !");
        return this->tobject;
    }


    void unlock()
    {
        locked = false;

        lock->unlock();
    }

    T *operator ->() const
    {   
        _ASSERT(locked);
        if (!locked)
            throw new std::exception("Synchronization error ! Object lock is already released !");

        return this->tobject; 
    }

    operator T *() const
    {
        _ASSERT(locked);
        if (!locked)
            throw new std::exception("Synchronization error ! Object lock is already released !");

        return this->tobject;
    }
};

感谢您提前提出任何评论和意见。

法提赫

Answer 1

您听说过德墨忒尔法则吗？

有一个类似的建议（我认为来自萨特）：不要共享对内部的引用

两者都是为了避免耦合，因为通过共享对内部的引用，这意味着您的公共接口泄漏了实现细节。

既然这么说，你的界面就不起作用了。

问题是您锁定的是代理，而不是对象：我仍然可以通过多个路径访问：

• 从 Foo，不需要互斥体 -->奥普斯？
• 来自两个不同的locked_object -->这似乎不是故意的...

更重要的是，一般来说，您不能锁定对象的单个部分，因为这样您就无法拥有整个对象的事务语义。

Answer 2

您的设计让用户有责任确保在正确的时间锁定和解锁对象。即使您锁定的对象进行了错误检查，它也没有涵盖所有基础（例如在完成对象时忘记释放该对象），

所以可以说您有不安全的对象TData。您将其包装在 Foo 中，但不是 Foo 返回指向 TData 的指针，而是重新实现 TData 中的所有公共方法在 Foo 中，但使用锁和解锁。

这与 pImpl 模式非常相似，只不过您的接口在调用实现之前添加了锁。这样用户只知道该对象是线程安全的，不需要担心同步。

Answer 3

这是多线程的核心问题，你不能要求客户端代码以线程安全的方式使用你的对象。你也不能真正做任何事情来帮助客户端代码落入成功的陷阱，它必须自己处理锁定。将让代码正常运行的责任交给最不可能正确执行的人。

您可以通过从访问器返回对象的副本来使其变得更容易。这是线程安全的，一个线程只会拥有一份副本。您可能应该使该副本的类型不可变，以强化修改对象不太可能获得所需的结果。一个无法解决的、可能会造成严重后果的副作用是，这个副本本质上是过时的。这些都是弊大于利的创可贴。

记录方法的填充，以便客户端程序员知道该怎么做。

Answer 4

这不是特别安全。没有什么可以阻止用户把事情弄乱：

locked_object<T> o(...);
T* t = o.get();
o.unlock();
t->foo(); // Bad!

当然，很容易看出为什么上面的代码很糟糕，但真正的代码要复杂得多，并且有很多方法可以使指针在锁释放后悬停。更难确定。