Контракты на кодекс - хорошо, на грани, но не готовы к прайм-тайм? - PullRequest
8 голосов
/ 08 февраля 2011

Я был действительно очарован контрактами кода, введенными в .NET 4 (хотя с помощью DevLabs).Но один мелкий шрифт немного охладил меня.Вот что он говорит:

  • В настоящее время нет обходного решения проблемы, когда постусловия вызываются вне блокировки в поточно-безопасном методе, за исключением того, что они не используются.
  • .NET полагаетсяна двоичном преобразователе, что замедляет сборку.
  • Использование контрактов кода также может привести к снижению производительности во время выполнения.
  • Не может использоваться для проверок, чувствительных к безопасности, поскольку их можно обойти во время выполненияпутем обработки события ContractFailed.

Самым большим для меня является первый.Я не знаю, пишут ли кто-нибудь однопоточные приложения больше.Поэтому, если контракты кода не способны поддерживать многопоточность, я не вижу большого их использования.Или, может быть, мне не стоит слишком сильно волноваться по этому поводу, потому что постусловия предназначены для утверждения внутренних частей самого метода, который может быть проверен модулем.

Кстати, я ничего не нашел и не пытался разобрать свой код, чтобы увидеть, куда вводятся предварительные условия.Я предполагаю, что в простом методе, когда lock () идет первым, просто внедрить проверки сразу после него, но в довольно сложном методе, когда блокировка происходит где-то посередине, это может быть проблемой.Или если используются другие механизмы, кроме lock ().

Ответы [ 2 ]

8 голосов
/ 08 февраля 2011

Вы, кажется, путаете «написание многопоточных приложений» с «превращением каждого класса в поточно-ориентированный». Оставляя в стороне сложный вопрос определения термина «безопасность потоков» Я бы предложил, чтобы очень немногие из ваших классов использовали блокировку в большинстве приложений.

Обычно я пишу много классов, которые не пытаются явно поточно-ориентированными, но в то же время не имеют никаких потоковых зависимостей. Они предполагают, что если вы собираетесь использовать их из нескольких потоков, вы будете делать это только из одного потока за раз, с соответствующими барьерами памяти, чтобы убедиться, что изменения, сделанные в одном потоке, видны в любом потоке, который их использует в следующем.

Тогда существует относительно несколько классов, которые выполняют необходимую координацию.

Теперь, возможно, проблемы с Code Contracts сделают эти несколько классов достаточно слабыми, чтобы заставить всю мысль рухнуть ... но я бы не предполагал, что для начала.

Я несколько более осторожен в вопросах, с которыми Code Contracts столкнется с тем, что компилятор C # выполняет все больше и больше работы по переписыванию вашего кода ... Я не знаю, занималась ли команда Contracts проблемами блоков итераторов, но даже если у них есть, им придется делать это снова, когда C # 5 выходит с асинхронными методами ...

3 голосов
/ 08 февраля 2011

В настоящее время нет обходного решения проблемы, когда постусловия вызываются вне блокировки в поточно-безопасном методе, за исключением того, что они не используются.

На самом деле не проблема - если вы выполняете проверку вне оператора блокировки в поточно-ориентированном методе, вы также можете столкнуться с проблемой. Отрегулируйте вашу реализацию для этого небольшого «ограничения». Вопрос в том, как переписчик кода узнает, что вы должны блокировать ресурс? Я думаю, что это ограничение будет оставаться в течение длительного времени.

.NET использует бинарный перезаписчик, что замедляет сборку.

Да, некоторые IL должны быть оценены, сгенерированы и сохранены, чтобы внедрить некоторые IL, чтобы построить новые зависимости = больше времени, конечно.

Использование контрактов кода также может привести к снижению производительности во время выполнения.

Также нет ничего необычного или проблемы, больше кода (генерируется для кода контрактов) = медленнее. В основном у вас есть больше кода и того, что вы можете выполнять через прокси-класс, так что больше кода + возможный прокси.

Не может использоваться для проверок, чувствительных к безопасности, поскольку их можно обойти во время выполнения путем обработки события ContractFailed.

Да, не делай этого. Вам даже не нужно отключать / собирать сборку, чтобы пропустить потенциальную проверку безопасности. Сохраняйте любые связанные с безопасностью потоки управления на сервере (будь то веб или БД), если это возможно, или попытайтесь запутать ваш код, насколько это возможно, если он локальный.

...