2016-05-13 102 views
9

我有两个函数foobar,它们应该是相互排斥的,因为它们对相同的数据进行操作。但foo复制了bar的很多代码,所以我想重构foo来致电bar相互调用的互斥函数

这是一个问题,因为然后我不能在两个函数中使用单个互斥锁,因为foo会在调用bar时发生死锁。所以,我只想要“互相排斥”,而不是“相互排斥”。

是否存在执行此操作的模式?我使用的是C++,如果我需要像shared_mutex这样的东西,我可以使用C++ 14/boost。

+0

使用'的std :: mutex'üerhaps? –

+0

将互斥量作为参数传递给共享代码的重构部分。 –

+2

@πάνταῥεῖ:“üerhaps”听起来像是你从度假带回家的疾病,或者是金属音乐会。 –

回答

20

定义的私人“解锁”功能,并使用来自foobar

void bar_unlocked() 
{ 
    // assert that mx_ is locked 
    // real work 
} 

void bar() 
{ 
    std::lock_guard<std::mutex> lock(mx_); 
    bar_unlocked(); 
} 

void foo() 
{ 
    std::lock_guard<std::mutex> lock(mx_); 
    // stuff 
    bar_unlocked(); 
    // more stuff 
} 
+0

是的,比可怕的递归互斥更好的解决方案。 – SergeyA

+0

相当明显(有相同的想法,但在这里太迟了) – Walter

4

另一种方式 - 这具有的优点是可以证明的是,锁已被采取:

void bar_impl(std::unique_lock<std::mutex> lock) 
{ 
    assert(lock.owns_lock()); 
    // real work 
} 

void bar() 
{ 
    bar_impl(std::unique_lock<std::mutex>(mx_)); 
} 

void foo() 
{ 
    // stuff 
    bar_impl(std::unique_lock<std::mutex>(mx_)); 
    // more stuff 
} 

理由:

std::mutex不是(由标准强制)是可移动的,但std::unique_lock<std::mutex>是。出于这个原因,我们可以将一个锁移入一个被调用者,并将其返回给调用者(如果需要的话)。

这使我们能够在呼叫链的每个阶段证明锁的所有权。

另外,一旦优化器参与,所有的锁定移动都可能被优化掉。这给了我们两全其美的好处 - 可证明的所有权和最佳表现。

一个更完整的例子:

#include <mutex> 
#include <cassert> 
#include <functional> 

struct actor 
{ 
    // 
    // public interface 
    // 

    // perform a simple synchronous action 
    void simple_action() 
    { 
    impl_simple_action(take_lock()); 
    } 

    /// perform an action either now or asynchronously in the future 
    /// hander() is called when the action is complete 
    /// handler is a latch - i.e. it will be called exactly once 
    /// @pre an existing handler must not be pending 
    void complex_action(std::function<void()> handler) 
    { 
    impl_complex_action(take_lock(), std::move(handler)); 
    } 

    private: 

    // 
    // private external interface (for callbacks) 
    // 
    void my_callback() 
    { 
    auto lock = take_lock(); 
    assert(!_condition_met); 
    _condition_met = true; 
    impl_condition_met(std::move(lock)); 
    } 


    // private interface 

    using mutex_type = std::mutex; 
    using lock_type = std::unique_lock<mutex_type>; 

    void impl_simple_action(const lock_type& lock) 
    { 
    // assert preconditions 
    assert(lock.owns_lock()); 
    // actions here 
    } 

    void impl_complex_action(lock_type my_lock, std::function<void()> handler) 
    { 
    _handler = std::move(handler); 
    if (_condition_met) 
    { 
     return impl_condition_met(std::move(my_lock)); 
    } 
    else { 
     // initiate some action that will result in my_callback() being called 
     // some time later 
    } 
    } 

    void impl_condition_met(lock_type lock) 
    { 
     assert(lock.owns_lock()); 
     assert(_condition_met); 
     if(_handler) 
     { 
     _condition_met = false; 
     auto copy = std::move(_handler); 
     // unlock here because the callback may call back into our public interface 
     lock.unlock(); 
     copy(); 
     } 
    } 



    auto take_lock() const -> lock_type 
    { 
    return lock_type(_mutex); 
    } 


    mutable mutex_type _mutex; 

    std::function<void()> _handler = {}; 
    bool _condition_met = false; 
}; 

void act(actor& a) 
{ 
    a.complex_action([&a]{ 
    // other stuff... 
    // note: calling another public interface function of a 
    // during a handler initiated by a 
    // the unlock() in impl_condition_met() makes this safe. 
    a.simple_action(); 
    }); 

} 
+0

更多的东西仍然在互斥锁运行? '将锁移入被调用者并将其返回给调用者'另一个选项是传递引用。 – jingyu9575