数据表和线程安全 [英] DataTable and thread safety

问题描述

我将DataTable存储在ASP .NET Cache属性中.可以在该DataTable上执行的操作是:

I'm storing DataTable in ASP .NET Cache property. Operations that can be done on that DataTable are:

• 绑定到网格控制(该第三方网格在内部管理数据源对象，回发其DataSource为NULL后，我认为一旦绑定数据，它将不再使用数据源DataTable)
• 从DataTable中删除行( Row.Delete()

在显式地处理该DataTable实例时，我添加了基本的读取器/写入器锁，但我想知道该解决方案是否还有其他线程安全问题.我猜想当网格控件位于DataBinding的中间时，其他线程可能会删除行吗?如果是这样，我该如何同步对该表的访问，以便在绑定网格控件时不进行任何 Delete 方法调用?我可以将AcquireWriterLock&放置在事件的任何组合中吗? ReleaseWriterLock方法?

I added basic reader/writer locks when explicitly working on that DataTable instance, but I wonder are there any other thread safety issues with that solution. I guess something might go wrong when grid control is in the middle of DataBinding, and other thread removes rows? If so, how can I sync access to that table so that no Delete method calls are made when grid control is binding? Are there any combination of events where I can put AcquireWriterLock & ReleaseWriterLock methods ?

谢谢，帕尔夫

推荐答案

如果您是通过数据绑定公开数据表的，那么就算了吧；您不能使该线程安全.即使您以某种方式包装了DataView(在自定义的ITypedList中)，这也做不到-数据绑定对数据(尤其是IList等)进行了假设-例如，它不是在迭代数据或在UI线程上添加一行时，将以线程竞争的方式随机更改长度.

If you are exposing the datatable via data-binding, then forget it; you cannot make that thread-safe. Even if you wrap the DataView somehow (in a custom ITypedList), that doesn't do enough - data-binding makes assumptions about the data, in particular the IList etc - for example, that it isn't going to randomly change length in a thread-contended way in the middle of iterating the data or adding a row on the UI thread.

有 可以通过事件在同一线程上进行 更改，但不能跨线程.

There is provision for changes on the same thread via events ... but not cross-threaded.

这篇关于数据表和线程安全的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！