如果我要更新 DataRow，我是锁定整个 DataTable 还是仅锁定 DataRow？
假设我从多个线程访问DataTable。如果我想访问特定行，我怀疑我需要锁定该操作（我可能会弄错，但至少我知道这样我是安全的）：
// this is a strongly-typed table
OrdersRow row = null;
lock (orderTable.Rows.SyncRoot) {
row = orderTable.FindByOrderId(myOrderId);
}
但是，如果我想更新< /em> 该行，我应该再次锁定表（或者更确切地说，表的 Rows.SyncRoot 对象），还是可以简单地锁定该行？
Suppose I'm accessing a DataTable from multiple threads. If I want to access a particular row, I suspect I need to lock that operation (I could be mistaken about this, but at least I know this way I'm safe):
// this is a strongly-typed table
OrdersRow row = null;
lock (orderTable.Rows.SyncRoot) {
row = orderTable.FindByOrderId(myOrderId);
}
But then, if I want to update that row, should I lock the table (or rather, the table's Rows.SyncRoot object) again, or can I simply lock the row?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
实际上，仅在 DataTable 或 DataRow 上的一处执行
锁定实际上并不会执行任何操作。使用Monitor锁（这就是lock块）时要记住的一个重要方面是，锁定对象不会对其执行任何操作；它只会对对象执行任何操作。这是一些人提倡使用专用锁定对象而不是锁定资源本身的原因之一，因为它迫使您意识到每当处理资源时都必须执行锁定（并且在同一对象上）。话虽如此，最好锁定整个 DataTable，因为数据存储本身就在那里（DataRow 对象内部仅包含 DataTable 的偏移量） 关于在哪里检索数据）。因此，即使您同步对各个行的访问，同时更新两个不同的行也会导致您以非同步方式更新相同的数据存储机制。
将内部类型视为“黑匣子”和仅锁定您需要的内容（在本例中，这会导致您得出仅锁定行的错误结论）和尝试深入了解内部工作之间存在冲突类型并依赖于可能改变的实现细节。
结果是，现在您应该锁定整个
DataTable，以避免以非同步方式更新内部数据存储系统。Actually, just performing a
lockin one place on the DataTable or DataRow doesn't actually do anything. An important aspect to remember in usingMonitorlocks (which is what alockblock is) is that locking an object doesn't do anything to it; that's one reason that some advocate using dedicated locking objects rather than locking the resource itself, since it forces you to realize that you have to perform the lock (and on the same object) whenever you're dealing with the resource.That being said, it's a better idea to lock the entire
DataTable, as the data storage itself is there (theDataRowobjects internally only contain an offset into theDataTableas to where to retrieve the data). Because of this, even if you synchronize access to individual rows, updating two different rows simultaneously will cause you to update the same data storage mechanism in a non-synchronized manner.There's a conflict here between viewing internal types as a "black box" and locking only what you need to (which, in this case, would lead you to a faulty conclusion of only locking the row) and trying to gain insight into the internal workings of the type and relying on implementation details that could change.
The upshot is that, right now, you should lock the entire
DataTableto avoid updating the internal data storage system in a non-synchronized manner.您不需要锁定读取 - 只需锁定写入/更新。锁定尽可能少的数量，以确保数据一致性......通常只是您要更新的一行。如果要更新表之间的父/子关系，则需要锁定每个表中的每一行。
you don't need to lock for reads - just for writes / updates. lock the smallest amount that you can, to ensure data consistency... usually just the one row that you are updating. if you are updating parent / child relationships between tables, you'll need to lock each row in each table.
数据表仅对于多线程读取操作是安全的：
http:// /msdn.microsoft.com/en-us/library/system.data.datatable.aspx
http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/11b69e1a-ad6c-48d5-8e14-264af5b0692e< /a>
在阅读有关数据表的信息时，存在有关锁定表并允许您安全更新行中数据的能力的冲突信息。根据第二个链接，您可以锁定表并更新行。由于这是来自 MS MVP，我想说您可能可以锁定表并确定。
The datatable is only safe for multi threaded read operations:
http://msdn.microsoft.com/en-us/library/system.data.datatable.aspx
http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/11b69e1a-ad6c-48d5-8e14-264af5b0692e
On reading about the datatable there is conflicting information concerning the ability to lock the table and allow you to safely update data in a row. According to the second link you can lock the table and update the row. Being this is from a MS MVP, I would say that you probably can lock the table and be ok.