1

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

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

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

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

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

由于数据的频率很高(每秒 5000 个),我必须为收到的每个数据锁定。会不会导致性能问题?如何避免占用这么多锁。任何人都可以建议具有最少锁定的设计实现。请帮忙。

4

3 回答 3

1

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

但是,我怀疑您最好的选择是重新设计。我最喜欢的书是并行编程很难,如果是,你能做些什么呢?. 我读过的所有其他并行编程书籍都展示了如何使线程进行通信(例如,通过锁)。这本书展示了如何设计线程可以独立运行而无需通信(尤其是无需通过锁进行协调)。

于 2013-07-22T17:56:53.793 回答
1

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

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

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

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

于 2013-07-22T17:35:55.657 回答
1

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

于 2013-07-23T23:53:55.040 回答