.NET CLR - 对象引用同步

发布于 2024-11-30 13:57:12 字数 220 浏览 1 评论 0原文

在多线程 .NET 应用程序中,

假设第一个线程正在写入列表 第二个线程正在清除其中的所有项目。 第三个线程正在从列表中读取。

如果第二个和第三个线程在 CLR 级别上“真正”同时访问同一个列表对象,会发生什么情况。我的意思不是.NET 同步对象和锁定机制。

我的意思是,当 CLR 从引用(通过第三个线程)访问列表项时,如果引用指向的列表发生更改(通过第二个线程)会发生什么?

In a multhreaded .NET application,

Assume first thread is writing into a List
Second thread is clearing all the items in.
And third thread is reading from the list.

What happens if second and third threads access the same list object at "really" same time on CLR level. I am not meaning .NET synchronization objects and lock mechanism.

I mean, when CLR accesses to the list items from reference (by 3rd thread)), what happens if the list that is pointed by reference change (by 2nd thread)?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

等待圉鍢 2024-12-07 13:57:12

坏东西。

此类型的公共静态(在 Visual Basic 中共享)成员是线程安全的。 不保证任何实例成员都是线程安全的。

只要不修改集合,List 就可以同时支持多个读取器。枚举集合本质上不是线程安全的过程。在枚举与一个或多个写访问争用的极少数情况下,确保线程安全的唯一方法是在整个枚举期间锁定集合。要允许多个线程访问集合以进行读写,您必须实现自己的同步。

Bad stuff.

Public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.

A List<T> can support multiple readers concurrently, as long as the collection is not modified. Enumerating through a collection is intrinsically not a thread-safe procedure. In the rare case where an enumeration contends with one or more write accesses, the only way to ensure thread safety is to lock the collection during the entire enumeration. To allow the collection to be accessed by multiple threads for reading and writing, you must implement your own synchronization.

长安忆 2024-12-07 13:57:12

它爆炸了。由于枚举已更改,因此引发 InvalidOperationException

It blows up. InvalidOperationException is thrown since the enumeration has changed.

零時差 2024-12-07 13:57:12

如果您倾向于更新列表并在多线程代码中读取它,那么可能会发生很多失败,例如,假设我们有以下场景:

//c#
List<object> myList...

//at reading thread
if (myList.Count > 0)
{
    object item = myList[0];//get the item at the first index of the collection.
}

//at writing thread
myList.Clear();

写入线程正在更新列表同时读取器线程从列表中读取,因此假设执行如下:
读取器线程检查集合中是否有项目,并发现其中有一些项目“.Count > 0 is true”,因此它继续,但在到达下一行之前,线程上下文切换通过切换到写入器线程来暂停读取器线程,因此它执行其代码myList.Clear();,此时线程上下文切换回来到读取器线程继续执行,因此它尝试获取myList[0],但写入器线程此时集合为空,因此它将失败并出现异常 IndexOutOfRange

另一种情况是,如果读取器线程迭代使用 foreach 抛出集合,编写器线程只是更改集合“添加/删除”一些项目,它会再次抛出异常,因为循环时集合发生更改。

所以你必须使用一些同步机械化与交互时列表,例如 C# 中的 lock 或使用 Monitor 类。但是,如果您使用的是 4.0,您可以切换到使用 ConcurrentCollection< /code> 它们不是普通的列表,而是线程安全的集合。

There is so many failures could occurs, if you tends to update the list and read it in multithreading code, for instance lets say we have the following scenario:

//c#
List<object> myList...

//at reading thread
if (myList.Count > 0)
{
    object item = myList[0];//get the item at the first index of the collection.
}

//at writing thread
myList.Clear();

The writing thread is updating the list at the same time the reader thread is reading from the list, so suppose the execution was as the following:
The reader thread check if there is an items at the collection, and it find that there is some itms on it ".Count > 0 is true" so it proceed, but before it reaches the next line, the thread context switching pause the reader thread by switching to the writer thread, so it execute the its code myList.Clear(); at that point the thread context switches back to the reader thread to continue its execution, so it tries to get myList[0], but the collection was empty at that point by the writer thread, so it will fail with exception IndexOutOfRange..

Another scenario that if the reader thread where iterating throw the collection using foreach, and the writer thread just changes the collection "added/removed" some items, it will throw exception again because of the collection changed while looping..

So you have to use some synchronization mechanizem when interacting with the list such as lock in C# or using Monitor class.. However if you are using 4.0 you can switch off to using ConcurrentCollection instead of normal lists, they are thread safe collections.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文