易失性应该与（非并发）集合一起使用吗？
我熟悉 易失性 的基本思想（总而言之，防止编译器对涉及可从多个线程访问的值的指令进行优化），但我注意到我发现的示例涉及volatile 和 .NET 3.5 集合（不是 .NET 4 Concurrent 集合。我知道它们是什么，但我当前的上下文不允许我使用 .NET 4。）从来没有应用了易失性到收藏本身。当然，从多个线程访问集合（或相应的锁定对象）时需要锁定它，但是是否有理由不将集合标记为易失性 ？集合的类型是否重要（即值类型的 List 与引用类型的 List）？
I'm familiar with the basic idea of volatile (to prevent compiler optimization of instructions involving values that may be accessed from multiple threads, in summary), but I've noticed that examples I've found involving volatile and .NET 3.5 collections (NOT .NET 4 Concurrent collections. I know what they are but my current context does not allow me to use .NET 4.) never have volatile applied to the collection itself. Of course the collection (or a corresponding locking object) will need to be locked when accessing it from multiple threads, but is there a reason that a collection should not be marked volatile? Is the type of collection significant (i.e. a List of value types versus a List of reference types)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
几乎可以肯定，挥发性并不意味着您所认为的那样。这是不使用它的主要原因。 （这些天我拒绝尝试描述 volatile 的含义。它太复杂了，无法清楚地解释，而且它几乎总是错误的方法，除非你是内存模型专家，在这种情况下你绝对不需要我< /em> 向您解释一下。）
如果您锁定了一个适当的对象，您认为它会给您带来什么好处？在获取和释放锁时，您已经要经过适当的内存栅栏了...我怀疑对变量本身使用 易失性 的任何原因都是基于误解。
Volatile almost certainly doesn't mean what you think it does. That's the main reason for not using it. (These days I refuse to try to describe what volatile means. It's too complicated to explain neatly, and it's almost always the wrong approach unless you're a memory model expert, in which case you definitely don't need me to explain it to you.)
If you're locking on an appropriate object, what benefit do you believe it will give you? You're already going to be going through appropriate memory fences in acquiring and releasing the lock... I suspect any reasons for using
volatilefor the variable itself are based on a misunderstanding.除非您实际上更改了集合的引用（即，重复地将新集合分配给引用集合的变量），否则没有理由将该变量标记为
易失性（也就是说，它不是做你认为它会做的事）。即使您是（然后我会质疑您在做什么？？？），如果您正确锁定，则不清楚您是否需要
易失性。顺便说一句，这门课真的很难。真的，真的，真的很难。
Unless you are actually changing the reference for the collection (i.e., repeatedly assigning a new collection to a variable referring to a collection) there is no reason to mark that variable as
volatile(that is, it is not doing what you think it does).Even if you are (and then I will question what you are doing???), it's not clear that you would need
volatileif you arelocking properly.By the way, this subject is really hard. really, Really, REALLY hard.
如果您不更改引用（即创建一个全新的不相关集合并在字段中替换它），那么
易失性将不会执行任何操作。就我个人而言，我可能会在线程密集型情况下将集合字段设为只读，只是为了防止意外（并使用锁）。所以很可能：不。
If you aren't changing the reference (i.e. creating an entire new unrelated collection and replacing that in the field), then
volatilewill do nothing. Personally, I'd probably make the collection fieldreadonlyin thread-intensive cases just to prevent accidents (and uselock).So probably: no.
你只需要使用一把锁。您所描述的内容中没有要求
易失性。You just need to use a lock. There's no call for
volatilein what you describe.如果你用易失性标记集合，你只是标记引用本身，而不是整个集合。
If you mark collection by volatile you just mark reference itself, not a whole collection.