当添加但不从List T中读取时的竞争条件.(或堆栈或队列)-会发生什么? [英] Race conditions when adding to, but not reading from, a List<T> (or Stack or Queue) - what happens?

查看:53
本文介绍了当添加但不从List T中读取时的竞争条件.(或堆栈或队列)-会发生什么?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

注意:我要问的是相对于3.5框架的问题,所以我没有在4.0(我还在学习)中包括任何较新的多线程结构.

Note: I'm asking this question relative to the 3.5 framework, so I'm not including any of the newer multithreaded constructs in 4.0 (which I'm still learning).

我一直在努力想出一个答案,以试图结束我一直以来的争论,但是我不觉得我已经找到了关于可能发生或可能发生的结论性描述.在以下情况下.

I've been trying to come up with an answer on this to try and close out an argument I've been having, but I don't feel like I've found a conclusive description as to what would or could happen in the following scenario.

假设您有一个包含多个线程的应用程序,所有线程均生成对象,每个线程均生成唯一的对象.集合的一个实例(列表,堆栈或队列)是对象创建后的存储库,并且一旦添加到集合中,对象实际上是不可变的.

Say you have an app with multiple threads that are all generating objects, with each thread generating a unique object. There's a single instance of a collection (List, Stack, or Queue) that's the repository for the objects once they've been created, and the objects are effectively immutable once added to the collection.

在此过程中,对集合的唯一操作是添加项目.无需阅读,删除或计数.集合中项目的顺序无关紧要.

During this process, the only operation on the collection is adding items. There's no reading, removing, or counting done. It doesn't matter what the order of the items are in the collection.

问题是,如果各个线程尝试添加对象时在集合周围没有锁定,那真的有问题吗?

The question is, if there is no locking around the collection when the individual threads are trying to add objects, is that really a problem?

我说是的,但是几乎所有关于种族条件为何成问题的教科书描述都在一端读了而在另一端读了,或者正在写一个变量,所以我没有足够的证据来证明有效地论证我的情况.

I say yes, but pretty much all of the textbook descriptions of why race conditions are problematic have a read on one end and a race on the other or are writing to a single variable, so I don't have enough evidence to argue my case effectively.

我之所以说是",基本上是因为这些集合并不是为线程安全而设计的,因此即使只执行写"操作,您也可能会遇到意想不到的或未定义的行为.我猜可能存在两个线程可能尝试将其对象添加到集合中同一插槽中的风险,因此,当对象被覆盖时,您会丢失该对象,但是我没有发现任何表明它是确实有可能.或可能存在一些幕后问题,例如何时收藏需要增长以容纳更多物品.

My reason for saying yes is basically down to the fact that the collections are not designed to be thread safe, so you could wind up with unexpected or undefined behavior, even if only "writes" are being performed. I'd guess that there is a risk that two threads might try adding their object to the same slot in the collection, and therefore you'd loose an object when it gets overwritten, but I haven't found anything that says that it is indeed possible. Or that there might be some behind-the-scenes problems, such as when the collection needs to grow itself to accommodate more items.

有人可以向我提供一些信息来帮助消除这种争论吗?我特别想知道是否有任何事情可以证明我做错了.

Can someone provide me with some information to help put this argument to rest? I'm especially interested to hear if there's anything that would prove me wrong.

推荐答案

将项目添加到 List< T> (或堆栈等)不是线程安全的

Adding items to a List<T> (or stack, etc) is not thread-safe.

这涉及

  • 检查内部数组大小是否足够
  • 如果没有,请创建一个新数组,复制所有项目
  • 在数组中设置索引等于 List< T>
  • 的长度的项目
  • Checking if internal array size is sufficient
  • If not, create a new array, copy all items
  • Set item in the array with the index equal to the length of the List<T>

以上所有过程都不是线程安全的,并且.NET Framework代码中没有同步.因此,如果您不同步,我保证您的列表将被破坏.

None of the above processes are thread safe and there are no synchronisation in .NET framework code. So if you do not synchronise, I guarantee your list will be corrupted.

这篇关于当添加但不从List T中读取时的竞争条件.(或堆栈或队列)-会发生什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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