通过订购std :: mutex

编程问答 2022-06-04

问题描述

这里是否存在可避免死锁逻辑的可移植实现（请参见标记为“ NON-PORTABLE”的部分）：

#include <cstdint>
#include <iostream>
#include <mutex>
#include <thread>

typedef long Money; //In minor unit.

class Account {
public:
    bool transfer(Account& to,const Money amount);
    Money get_balance() const;
    Account(const Money deposit=0) : balance{deposit} {}
private:
    mutable std::mutex lock;
    Money balance;
};

bool Account::transfer(Account& to,const Money amount){
    std::unique_lock<decltype(this->lock)> flock{this->lock,std::defer_lock};
    std::unique_lock<decltype(to.lock)> tlock{to.lock,std::defer_lock};
//NON-PORTABLE:BEGIN: using intptr_t AND assuming Total Strict Order.
    const auto fi{reinterpret_cast<const std::intptr_t>(static_cast<const void*>(&this->lock))};
    const auto ti{reinterpret_cast<const std::intptr_t>(static_cast<const void*>(&to.lock))};
    if(fi<ti){
        flock.lock();
        tlock.lock();
    } else if (fi!=ti) {
        tlock.lock();
        flock.lock();
    } else {
        flock.lock();
    }
//NON-PORTABLE:END  
    this->balance-=amount;
    to.balance+=amount;
    return true;
}

Money Account::get_balance() const{
    const std::lock_guard<decltype(this->lock)> guard{this->lock};
    return this->balance;
}

void hammer_transfer(Account& from,Account& to,const Money amount,const int tries){
    for(int i{1};i<=tries;++i){
        from.transfer(to,amount);
    }
}

int main() {
    constexpr Money open_a{ 200000L};
    constexpr Money open_b{ 100000L};
    constexpr Money tran_ab{10};
    constexpr Money tran_ba{3};
    constexpr Money tran_aa{7};

    Account A{open_a};
    Account B{open_b};
    
    std::cout << "A Open:" << A.get_balance() << '\n';
    std::cout << "B Open:" << B.get_balance() << '\n';
    
    constexpr long tries{20000}; 
    std::thread TAB{hammer_transfer,std::ref(A),std::ref(B),tran_ab,tries};
    std::thread TBA{hammer_transfer,tran_ba,tries};
    std::thread TAA{hammer_transfer,tran_aa,tries};

    TAB.join();
    TBA.join();
    TAA.join();

    const auto close_a{A.get_balance()};
    const auto close_b{B.get_balance()};   
    
    std::cout << "A Close:" << close_a<< '\n';
    std::cout << "B Close:" << close_b<< '\n';
    
    int errors{0};
    if((close_a+close_b)!=(open_a+open_b)){
        std::cout << "ERROR: Money Leaked!\n";
        ++errors;
    }
    if(close_a!=(open_a+tries*(tran_ba-tran_ab)) ||
          close_b!=(open_b+tries*(tran_ab-tran_ba))
    ){
        std::cout << "ERROR: 'Lost' Transaction(s)\n";
        ++errors;
    }
    if(errors==0){
        std::cout << "* SUCCESS *\n";
    }else{
        std::cout << "** Failed **\n";
    }
    std::cout << std::endl;
    return 0;
}

可在此处运行：https://ideone.com/hAUfhM

这样的假设是（而且我相信足够吗？有人吗？）存在intptr_t并且intptr_t上的关系运算符暗含了它们表示的指针值的总严格排序。

假定的排序不能得到保证，并且比指针的不可移植性（例如，如果intptr_t宽于指针并且不是所有位都被写入），则可移植性较差。

我知道对此设计和其他设计有一些不同的重复之处。 我会推荐所有好的答案，即使它们不是可移植的，也可以用来确定他们对实现的假设，理想情况下是一个适用的平台，最好是一个不适用的平台！

解决方法

std :: lock（）具有避免死锁的内置算法。

https://en.cppreference.com/w/cpp/thread/lock

,

一旦开始出现锁争用，您将失去使用此方法的功能，需要重新考虑整个解决方案。而且几乎所有的锁都会导致上下文切换，每个上下文切换将花费大约20000个周期。

通常，大多数帐户都有很多入库（商店，安排）或支出（养老金，救济金等）

一旦确定了有争议的帐户，您可以将很多交易排队，然后锁定该帐户并通过try_lock另一个帐户运行该交易，如果锁定成功，则交易完成。尝试两次try_lock，然后对两个锁都进行scope_lock，其余的将所有这两个事务都共用。

第2部分。 通过比较不在同一区域的指针，我该如何确保我的锁的安全排序？

您将一个唯一的ID添加到该帐户，然后在该帐户上进行比较！

,

tl; dr -您可以在C ++ 20中方便地进行原始指针比较。我可能会将代码包装到scoped_ordered_lock之类的东西中，因为代码仍然有些毛病。

这样的假设是（而且我相信足够了，有人吗？）存在intptr_t，并且在将值从有效的非空指针强制转换为std :: mutex时，intptr_t上的关系运算符暗含对值的完全严格排序。 >

不完全是。您做总是对积分值有严格的严格排序。当从intptr_t到指针的映射是多对一时会出现问题（分段地址示例here就是这种情况，即intptr_t上的TSO不够）。

指向intptr_t映射的指针也必须是内射的（不必是双射的，因为我们不在乎某些intptr_t的值是否未使用/不表示有效的指针）。

无论如何，很明显，可以存在对指针 的完全严格的排序：这只是特定于实现的。分段的地址可以规范化或展平，等等。

幸运的是，由C ++ 20中的三向函子std::compare_three_way和两向函子less，{{1}提供了合适的实现定义的总严格排序。 }等在C ++ 20之前（在C ++ 20中也可能是 ）。

关于implementation-defined strict total order over pointers的文本中，没有关于spaceship operator的等效语言-尽管greater被描述为是调用该语言-或关于其他关系运算符。

这似乎是有意的，因此内置运算符compare_three_way，< 、、 >，<=和>=不会获取新的在某些平台上可能很昂贵的约束。实际上，两向关系运算符已明确地描述为指针上的partial order。

因此，这应该与您的原始代码相同，但可移植的除外：

<=>

注意

  • 从C ++ 20起（尤其是PDF：P1961R0），[comparisons.general]说

    对于模板const auto order = std::compare_three_way{}(&this->lock,&to.lock); if(order == std::strong_ordering::less){ flock.lock(); tlock.lock(); } else if (order == std::strong_ordering::greater) { tlock.lock(); flock.lock(); } else { flock.lock(); } ，less，greater和less_­equal，任何指针类型的特殊化都产生与实现定义的指针总严格顺序一致的结果

    这是一个较弱的要求，它允许他们提供部分订单，只要它永远不会与总订单不一致。目前尚不清楚这是否是有意削弱，还是仅表示他们必须实现在其他地方定义的相同总顺序。

  • C ++ 20之前的版本 greater_­equal等。 did 需要这些函子的总订单。

无论如何，如果您无权使用C ++ 20和less，那么您的compare_three_way等将得到保证。 可以保证为您提供所需的全部订购服务。只是不要依赖原始的关系运算符。

,

这是显示修改后的代码的自我答案。这归功于上面接受的答案。 我的学习是，由于C ++ 14 std::less，std::greater等在指针上定义了严格总计，该指针与<和{{1 }}等。

通过使用这些模板，现在可以确保此代码无死锁。 在C ++ 20中，可以使用>使它更整洁，并且可能更快。

https://ideone.com/ekuf2f 

std::compare_three_way<>
c++c++14concurrencyconcurrencylanguage-lawyerportability