实现一个无锁队列（对于记录器组件） [英] Implementing a lock-free queue (for a Logger component)

问题描述

我设计一个新的改进记录器组件（.NET 3.5，C＃）。

I am designing a new improved Logger component (.NET 3.5, C#).

我想用一个无锁的实现。

I would like to use a lock-free implementation.

记录的事件将（可能）多线程发送，虽然只有一个的单的线程会做实际输出到文件/其它存储介质。

Logging events will be sent from (potentially) multiple threads, although only a single thread will do the actual output to file/other storage medium.

在本质上，所有的作家是*入队*的数据转换成一些队列，要通过一些其他进程（LogFileWriter）检索。

In essence, all the writers are * enqueuing* their data into some queue, to be retrieves by some other process (LogFileWriter).

这能在锁定少的方式实现？我找不到一个直接引用在网络这个特定的问题。

Can this be achieved in a lock-less manner? i could not find a direct reference to this particular problem on the net.

推荐答案

如果你发现在这种情况下使用锁太慢了，你有一个更大的问题。锁定，当没有争辩，把我的系统（2.0 GHz的Core 2四核）在大约75纳秒。当它的主张，当然，这将在一定程度需要更长的时间。但由于锁只是保护调用排队或出列，这是不可能的总时间日志写入。将低于75纳秒多

If you find that using a lock in this case is too slow, you have a much bigger problem. A lock, when it's not contended, takes about 75 nanoseconds on my system (2.0 GHz Core 2 Quad). When it's contended, of course, it's going to take somewhat longer. But since the lock is just protecting a call to Enqueue or Dequeue, it's unlikely that the total time for a log write will be much more than that 75 nanoseconds.

如果锁的是的一个问题 - 那就是，如果你发现你的线程排队的背后在您的应用程序锁定，并造成显着放缓 - 那么它是不太可能实现无锁队列什么帮助。为什么？因为如果你真的写那么多的日志，你无锁阻塞队列是要填补如此之快，你会被限制在I / O子系统的速度。

If the lock is a problem--that is, if you find your threads lining up behind that lock and causing noticeable slowdowns in your application--then it's unlikely that making a lock-free queue is going to help much. Why? Because if you're really writing that much to the log, your lock-free blocking queue is going to fill up so fast you'll be limited to the speed of the I/O subsystem.

我有200日志的顺序写了一个多线程应用程序条目的第二到问答LT;串> ，用一个简单的锁保护。我从来没有发现任何显著锁争用，并处理未在毫厘放缓。 75 ns的是它需要做的一切的时候小巫见大巫了。

I have a multi-threaded application that writes on the order of 200 log entries a second to a Queue<string> that's protected by a simple lock. I've never noticed any significant lock contention, and processing isn't slowed in the least bit. That 75 ns is dwarfed by the time it takes to do everything else.

这篇关于实现一个无锁队列（对于记录器组件）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！