C++/CLI 高效多线程循环缓冲区
我正在开发的 C++/CLI GUI 中有四个线程：
- 收集原始数据
- GUI 本身
- 一个后台处理线程，它获取原始数据块并生成有用的信息
- 充当控制器，连接
我已经得到的 其他三个线程原始数据收集器工作并将结果发布到控制器，但下一步是存储所有这些结果，以便 GUI 和后台处理器可以访问它们。
新的原始数据以固定（频繁）的间隔一次输入一个结果。 GUI 将在每个新项目到达时访问它（控制器宣布新数据，然后 GUI 访问共享缓冲区）。数据处理器将定期读取缓冲区的一块（例如一秒钟）并产生新的结果。实际上，有一个生产者和两个消费者需要访问。
我到处寻找，但 CLI 提供的东西听起来都不太有用，所以我正在考虑自己动手。共享循环缓冲区，允许收集器的写锁和 GUI 和数据处理器的读锁。只要缓冲区的这些部分没有被写入，这将允许多个线程读取数据。
所以我的问题是：.net 库中是否有任何简单的解决方案可以实现这一目标？我因为考虑自己推出而生气了吗？有更好的方法吗？
I have four threads in a C++/CLI GUI I'm developing:
- Collects raw data
- The GUI itself
- A background processing thread which takes chunks of raw data and produces useful information
- Acts as a controller which joins the other three threads
I've got the raw data collector working and posting results to the controller, but the next step is to store all of those results so that the GUI and background processor have access to them.
New raw data is fed in one result at a time at regular (frequent) intervals. The GUI will access each new item as it arrives (the controller announces new data and the GUI then accesses the shared buffer). The data processor will periodically read a chunk of the buffer (a seconds worth for example) and produce a new result. So effectively, there's one producer and two consumers which need access.
I've hunted around, but none of the CLI-supplied stuff sounds all that useful, so I'm considering rolling my own. A shared circular buffer which allows write-locks for the collector and read locks for the gui and data processor. This will allow multiple threads to read the data as long as those sections of the buffer are not being written to.
So my question is: Are there any simple solutions in the .net libraries which could achieve this? Am I mad for considering rolling my own? Is there a better way of doing this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是否可以重新表述该问题，以便：
如果线程之间传递的值在共享后不会被修改，则这可能会避免您需要自定义线程安全集合类，并减少所需的锁定量。
Is it possible to rephrase the problem so that:
If the values passed between threads are not modified after they are shared, this might save you from needing the custom thread-safe collection class, and reduce the amount of locking required.