避免频繁锁定

时间:2013-07-22 17:26:03

标签: c++ multithreading locking

我的程序从交换中获取大量数据。数据被解析为tick对象。一个典型的刻度

struct Tick
{
    string ID;
    int bidprice[5];
    int askprice[5];
    int totalTradedQuantity;
    int totalTradedVolume;
    .....
    .....
}

此tick对象发布到网络并记录在文件中。目前我正在锁定更新刻度和发布。

Parser Part:
lock();
tick update
unlock();

Publisher Part:
lock();
tick publish;
unlock();

由于数据频率很高(每秒5000次),我必须对收到的每个数据进行锁定。它会导致性能问题吗?我怎么避免这么多锁。任何人都可以提出最小锁定的设计实现。请帮忙。

3 个答案:

答案 0 :(得分:1)

锁定或信号量是防止竞争条件的唯一工具。

信号量将阻止忙碌的等待。但是锁(特别是自旋锁)会导致繁忙的等待。 (在您的情况下,数据频率很高;您不必担心忙碌等待。)

但是,部署到CPU的非常有效且快速的锁定机制。在这种情况下,您不必担心锁定和解锁开销。

此外,您始终可以选择对请求进行排队并在锁定和处理过程中对其进行处理。解锁部分。

答案 1 :(得分:1)

因为您需要互斥,所以您需要锁定。使用当前设计可以做的最好的事情就是使用不寻常的锁。例如,如果您阅读的内容多于您编写的内容,则可以使用读取器/写入器锁。如果线程之间几乎没有争用,并且同一个线程通常需要连续多次锁定,那么你可能会从偏向锁中获得性能提升。

然而,我怀疑你更好的选择是重新设计。我最喜欢的关于此事的书是 Is Parallel Programming Hard, and, If So, What Can You Do About It? 。我读过的所有其他并行编程书都展示了如何使线程进行通信(例如,通过锁)。本书介绍了如何进行设计,以便线程可以独立运行而无需通信(尤其是,无需通过锁定进行协调)。

答案 2 :(得分:1)

锁定也不错。锁争用很糟糕。你有几把锁?每个刻度一个,每个ID一个,总共一个?通常最简单的解决方案是避免单个集中锁定。