代码合同 - 很好,在边缘,但尚未准备好黄金时间？

Question

我对.NET 4中引入的代码契约感到非常着迷(尽管在DevLabs的帮助下).但是一个好的打印让我冷静下来.这是它说的:

对我来说最大的是第一个.我不知道是否还有人编写单线程应用程序.因此,如果代码契约不能支持多线程,我看不到它们的用处.或者也许我不应该过分强调这一点,因为后置条件是用于断言方法本身的内部,可以进行单元测试.

顺便说一句,我还没有找到任何东西,我没有尝试反汇编我的代码,看看注入了哪些先决条件.我想在一个简单的方法中,当lock()首先出现时,在它之后立即注入检查很简单,但是在一个相当复杂的方法中,当锁定发生在中间的某个地方时,这可能是一个问题.或者,如果使用除lock()之外的其他一些机制.

Answer 1

你似乎把"编写多线程应用程序"与"让每个类都线程安全"混淆.暂且不谈定义术语"线程安全"的棘手问题,我建议你的类很少应该在大多数应用程序中使用锁定.

通常我会写很多类,这些类不会尝试显式线程安全,但同样没有任何线程依赖.他们假设如果你要从多个线程中使用它们,你只能从一个线程一次这样做,并且有适当的内存障碍,以确保在下一个使用它们的任何线程中可以看到一个线程中所做的更改.

然后,相对较少的类执行必要的协调.

现在,代码合同的问题可能会让那些少数类足够弱,以至于整个思想都会崩溃......但我不会假设这一点开始.

我对Code Contracts将面临的问题更加谨慎C#编译器正在做越来越多的工作重写你的代码...我不知道Contracts团队是否已经解决了迭代器块的问题,但即使他们有当C#5推出异步方法时,我们必须再次这样做......

Answer 2

\n
当在线程安全方法中的锁之外调用后置条件时，除了不使用它们之外，当前没有解决该问题的方法。
\n

\n\n

并不是真正的问题\xe2\x80\x94如果您在线程安全方法的锁定语句之外进行检查，您也可能会遇到问题。针对这个小小的“限制”调整您的实现。问题是代码重写器如何知道您必须锁定资源？我认为这种限制将持续很长一段时间。

\n\n

\n
.NET 依赖于二进制重写器，因此使构建速度变慢。
\n

\n\n

是的，必须评估、生成和保存一些 IL，以注入一些 IL 构建新的依赖项 = 当然需要更多时间。

\n\n

\n
使用代码契约也可能会导致运行时性能下降。
\n

\n\n

这也不是不寻常或问题，更多的代码（为代码合约生成）=更慢。基本上你只是有更多的代码以及你可能通过代理类运行的代码，所以有更多的代码+可能的代理。

\n\n

\n
不能用于安全敏感检查，因为可以在运行时通过处理 ContractFailed 事件来规避它们。
\n

\n\n

是的，不要这样做。您甚至不必拆卸/重新组装程序集即可跳过潜在的安全检查。如果可能的话，将所有与安全相关的控制流保留在服务器上（无论是 Web 还是数据库），或者在本地尝试尽可能地混淆代码。

\n