ConcurrentQueue< StrongBox<>>的用法是: [英] Usage of ConcurrentQueue<StrongBox<T>>

问题描述

我基本上是在寻找从一个线程中从相机获取的图像集合的容器.由于ConcurrentQueue是线程安全的，因此我想使用它.但是在调试代码时，我发现

I am basically looking for a container of image collections acquired from camera in a thread. Since ConcurrentQueue is thread-safe, I wanted to use it. But while debugging my code, I found this article saying

如果元素很小，您可能永远不会注意到这一点.如果， 但是，这些元素会占用大量资源(例如，每个元素都是 巨大的图片位图)，有可能您会看到此效果 (一种解决方法是将包装器对象排队，例如让一个 ConcurrentQueue<StrongBox<T>>而不是ConcurrentQueue<T>，并且 包装器完成后，将包装器对T值的引用无效 已出队).

If the elements are small, you’ll probably never notice this. If, however, the elements hold on to large resources (e.g. each element is a huge image bitmap), it’s possible you could see the impact of this (one workaround is to queue a wrapper object, e.g. have a ConcurrentQueue<StrongBox<T>> rather than a ConcurrentQueue<T>, and null out the wrapper’s reference to the T value after the wrapper has been dequeued).

据我所知，StrongBox是原始值的一种包装.这是否意味着我必须存储图像的另一个集合?

As far as I can see, StrongBox is a kind of wrapper for original value. Does that mean I have to store another collection of the images?

因此，我正在寻找ConcurrentQueue<StrongBox<T>>.的用法或示例.我从google找到的唯一内容是

So I am looking for an usage or an example of ConcurrentQueue<StrongBox<T>>. Only thing I found from google is this code.

推荐答案

关于过早优化的危险的提示已在注释中，因此我将在此讨论发生的事情的语义.

The reminder of the dangers of premature optimization are in the comments, so I will address the semantics of what's going on here.

就像文章指出的那样，ConcurrentQueue可以保留对已经经历过的某些事情的引用.我学到的是几十个"，而文章说不超过31个，这似乎很好地融合了.如果队列正在跟踪大型对象(例如2000x2000位图)，那么从理论上讲可能会成为问题.当然，这取决于程序的其余部分.

Like the article points out, the ConcurrentQueue can hold on to references of some things that have already gone through it. I learned it as 'a few dozen' and the article says it is no more than 31, which seems to gel pretty nicely. If the queue is tracking big objects, like your 2000x2000 Bitmaps, that can theoretically become a problem. It depends on what the rest of your program is doing, of course.

将其包装在 StrongBox<T> 中会有所帮助，因为StrongBox唯一要做的是保持对其他事物的引用.因此，StrongBox的占用空间非常小，并且它所拥有的任何内容都将超出范围，并且(从理论上来说)可以使GC更快.

Wrapping it in a StrongBox<T> helps because the only thing StrongBox does is hold onto a reference to something else. Therefore, a StrongBox has a very tiny footprint, and whatever it holds will go out of scope and (theoretically) get GC'd quicker.

由于StrongBox具有减肥汽水的所有含量，因此您有点过分考虑了其用法.您只需将T字段加载到Value字段中，然后在以后引用它.看起来有点像这样:

Since StrongBox has all the content of diet soda, you're kind of overthinking its usage. You literally just load up the Value field with some T and then reference it later. It looks a little like this:

var boxedBitmap = new StrongBox<Bitmap>(new Bitmap(1,1));
var bitmap = boxedBitmap.Value;

或者:

var boxedBitmap = new StrongBox<Bitmap>();
boxedBitmap.Value = new Bitmap(1,1);
var bitmap = boxedBitmap.Value;

严重的是，如果您在Reflector中打开它，则该类的实现就像5行一样.

Seriously, the implementation of this class if you pop it open in Reflector is like 5 lines.

在这种情况下，ConcurrentQueue<T>的用法与ConcurrentQueue<StrongBox<T>>的用法并没有什么不同.在将资源发送到目标线程之前，只需添加.Value即可.这确实帮助了我工作的一家公司，只需将引用传递给确定性工具，而不是传递整个工具，就可以大大减少大规模多线程分析服务的内存烙印，但是您的努力可能会有所不同-我不清楚如果您要传递某些东西进行突变然后再被其他东西使用，将会带来什么后果.

This being the case, your usage of ConcurrentQueue<T> is not really any different from the usage of ConcurrentQueue<StrongBox<T>>. You'll simply tack on .Value before you send the resource to its destination thread. This did help a company I worked for reduce the memory imprint of a massive multithreaded analysis service by quite a bit by simply passing around a reference to a deterministic tool instead of passing the entire tool around, but your mileage may vary - I am not clear on what ramifications it would have if you were passing something to be mutated and then used by something else.

这篇关于ConcurrentQueue< StrongBox<>>的用法是:的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！