多线程单读卡器单写器fifo队列 [英] Multithreaded single-reader single-writer fifo queue

查看:233
本文介绍了多线程单读卡器单写器fifo队列的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我需要一个队列,用于将消息从一个线程(A)传递到另一个线程(B),然而,我不能找到一个真正做我想要的,因为他们通常允许添加一个项目失败,在我的情况是非常致命的,因为消息需要处理,线程真的不能停止,等待空间。





  • 线程A不能阻止,但是线程B不是性能关键的,因此它可以

  • 添加项必须始终成功,因此队列不能有大小上限(系统上内存不足)

  • 如果队列为空,线程B应等待,直到有要处理的项目


解决方案

如何在C ++中编写无锁队列: / p>

http://www.ddj.com/ hpc-high-performance-computing / 210604448



但是当你说线程A不能阻塞时,你确定这是要求吗? Windows不是实时操作系统(也不是linux,正常使用)。如果你希望线程A能够使用所有可用的系统内存,那么它需要分配内存(或者等待别人做)。操作系统本身不能提供时序保证,比那些如果读者和作者采取一个进程内的锁(即非共享互斥)为了操纵列表。而添加消息的最坏情况是必须去操作系统获得内存。



总之,有一个原因你不喜欢的队列具有固定的容量 - 这是为了使他们不必在所谓的低延迟线程中分配内存。



因此,无锁代码通常会减少块-y,但由于内存分配不能保证,并且使用互斥体的性能不应该是破旧的,除非你有一个真正巨大的事件流来处理(比如,你正在编写一个网络驱动程序



因此,在伪代码中,我会尝试的第一件事是:

 作者:
分配消息并填入
获取锁
将附加节点附加到入侵列表
信号条件变量
释放锁

读取器:
for(;;)
获取锁
for(;;)
如果有节点
删除它
break
else
等待条件变量
endif
endfor
释放锁
进程消息
自由消息
endfor

只有当这证明在写线程中引入不可接受的延迟时,我才会锁定 - 免费代码,(除非我碰巧有一个合适的队列已经躺在)。


I need a queue for passing messages from one thread (A) to another (B), however ive not been able to find one that really does what I want, since they generally allow adding an item to fail, a case which in my situation is pretty much fatal since the message needs to be processed, and the thread really cant stop and wait for spare room.

  • Only thread A adds items, and only thread B reads them
  • Thread A must never block, however thread B is not performance critical, so it can
  • Adding items must always succeed, so the queue cant have an upper size limit (short of running out of memory on the system)
  • If the queue is empty, thread B should wait until there is an item to process

解决方案

Here's how to write a lock-free queue in C++:

http://www.ddj.com/hpc-high-performance-computing/210604448

But when you say "thread A must not block", are you sure that's the requirement? Windows is not a real-time operating system (and neither is linux, in normal use). If you want Thread A to be able to use all available system memory, then it needs to allocate memory (or wait while someone else does). The OS itself cannot provide timing guarantees any better than those you'd have if both reader and writer took an in-process lock (i.e. a non-shared mutex) in order to manipulate the list. And the worst-case of adding a message is going to have to go to the OS to get memory.

In short, there's a reason those queues you don't like have a fixed capacity - it's so that they don't have to allocate memory in the supposedly low-latency thread.

So the lock-free code will generally be less block-y, but due to the memory allocation it isn't guaranteed to be, and performance with a mutex shouldn't be all that shabby unless you have a truly huge stream of events to process (like, you're writing a network driver and the messages are incoming ethernet packets).

So, in pseudo-code, the first thing I'd try would be:

Writer:
    allocate message and fill it in
    acquire lock
        append node to intrusive list
        signal condition variable
    release lock

Reader:
    for(;;)
        acquire lock
            for(;;)
                if there's a node
                    remove it
                    break
                else
                   wait on condition variable
                endif
            endfor
        release lock
        process message
        free message
    endfor

Only if this proves to introduce unacceptable delays in the writer thread would I go to lock-free code, (unless I happened to have a suitable queue already lying around).

这篇关于多线程单读卡器单写器fifo队列的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆