锁定应该发生在 API 层、应用程序层还是两者兼而有之？答案

【问题标题】：Should locking occur at API layer, application layer, or both?锁定应该发生在 API 层、应用程序层还是两者兼而有之？
【发布时间】：2015-11-17 15:27:20
【问题描述】：

作为 API 设计者，执行锁检查以确保对象状态不会被调用者无效是否有意义？

考虑一个Grid3D 数据结构，它必须在每次更改其Width、Heigth 或Depth 时自行调整大小。如果调用者正在从多个线程修改Grid3D，则Grid 可能会在尝试重新调整大小时调整大小，这会使对象状态无效或引发异常。

这可以通过使用锁为 resize 函数提供互斥来克服，它可能发生在 API 中（即Grid3D 的类定义），也可能发生在Grid3D 所在的应用程序中被使用了。

如果在Grid3D 类定义中加锁是正确的，这就是说所有API 开发都应该考虑线程同步。在许多情况下（当然包括 StackOverflow 在内的许多在线示例）不考虑 API 级类中的同步。

那么，执行锁定的正确位置在哪里？ API 级别在什么情况下应该关注锁定？

【问题讨论】：

奇怪，这个话题太宽泛了，实际上我错过了任何细节。所以我们实际上可以用 20 种不同的方式来回答这个问题，它们都是正确的。这就像问，明天是否会是美好而闪亮的一天，而不是指定任何位置:)。

【解决方案1】：

这是你的设计决定，你可以创建一个线程安全的类，或者你可以以线程安全的方式将使用它的任务委托给使用它的人。

当它们不打算在多线程环境中使用时，通常库不提供类的线程安全实例。如果你的类的主要用途是在多线程环境中，你应该处理线程安全。

你可以在 MSDN 中看到这句话数百万次

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

这意味着该类的实例默认情况下不打算在多线程环境中使用，但您 can see also classes 默认支持内置同步并准备在多线程环境中使用。

正如我所见，Grid3D 是一个 UI 组件，通常 UI 组件被构建为仅供创建它们的线程使用。

【讨论】：

【解决方案2】：

这取决于 API 是否应该是线程安全的。如果是，那么 API 层应该关注锁定，否则不应该。

例如，看看System.Threading.Thread 和System.Array 类。 Thread 是线程安全的，它是这样记录的（参见线程安全部分），而 Array 不是线程安全的，并且在文档中指出它的“......任何实例成员都不能保证是线程安全的” .

【讨论】：