Question

我有std::map<int, Object*> ObjectMap。现在我需要更新地图并通过多个线程进行更新。因此，我们锁定地图以进行更新。但是每次更新都会导致冗长的计算，从而导致锁争用。

让我们考虑以下情况。

class Order  //Subject      
{ double _a, _b,_c;   
  std::vector<Customer* > _customers;  

  public:           
  void notify(int a, int b. int c)
  {    
     //update all customers via for loop. assume a for loop and iterator i    
     _customers[i] ->updateCustomer(a,b,c)
  }      

};
class SomeNetworkClass
{
private:
   std::map<int, Order*> _orders;
public:
   void updateOrder(int orderId, int a, int b, intc)
   {     
    //lock the map
      Order* order = _orders[orderId];
      order->notify();
    //release the lock
   }     
}

class Customer
{
public:
   void updateCustomer(int a,int b, int c)
   {
    //some lengthy function. just for this example. 
    //assume printing a, b and c multiple times
   }
}

每个客户也会更新一些涉及的计算。现在这是一个简单的观察者模式。但是，每个观察者都有大量的观察者和巨大的计算，这是这种设计的杀手锏。锁争用在我的代码中上升。我认为这是一个实际问题，但人们使用更聪明的方式，我正在寻找那些更聪明的方法。我希望这次我有点清楚

由于希夫

Answer 1

由于更新发生在地图的元素上，并且没有将地图作为参数，我假设地图是不变的。

我将结构可视化为每个地图ID的对象链。现在，如果链包含不同的条目（并且更新不访问其链外的任何元素或任何全局元素），您可以通过向每个链的根元素添加锁来逃避。

但是，如果链中的对象可能被共享，那么您就会遇到更困难的问题。在这种情况下，为每个对象添加一个锁就足够了。您可以证明，如果链的行为正确（每个节点都有一个子节点，但子节点可以共享），则必须以一致的顺序获取锁，这意味着不存在死锁的可能性。

如果链之间存在其他共享，那么遇到死锁的可能性很大。

假设您有案例2，那么您的代码将大致与此类似

class Object
{
   Object * next;
   Lock l;
   Data d;
   void update(Data d_new)
   {
     l.lock();
     d = d_new;
     next->update(d_new);
     l.unlock();
   }
};

最小化锁争用c ++ std :: map

1 个答案: