Когда блокировка типов - хорошая идея?

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


multithreading c# thread-safety locking
person Firedragon    schedule 21.11.2011    source источник
comment
Разработчики языка не могут предвидеть каждое использование, которое понадобится программистам. Зачем ограничивать то, что может быть полезным для крошечной группы программистов?   -  person Oded    schedule 21.11.2011

Ответы (3)


arrow_upward
2
arrow_downward

Чтобы понять, почему это вообще плохая идея, посмотрите статью Не блокировать объекты типа.

Это разрешено, потому что разработчики языка / фреймворка решили заблокировать все, что происходит от System.Object. Никто не может предотвратить это, потому что System.Type является производным от System.Object (как и любой другой тип .NET).

Возьмите эту подпись:

void Foo(object o)

Как может компилятор обеспечить, чтобы o не было System.Type? Вы, конечно, можете проверить это во время выполнения, но это повлияет на производительность.

И, конечно же, могут быть суперэкзотические ситуации, когда нужно зафиксировать тип. Возможно, CLR делает это внутренне.

person Florian Greinacher    schedule 21.11.2011
comment
Ах, это многое объясняет. Поскольку typeof () возвращает объект типа, который можно заблокировать, он может разрешить блокировку, даже если в целом это плохая идея. Теперь я лучше понимаю. Спасибо! - person Firedragon; 21.11.2011

arrow_upward
4
arrow_downward

Это почти всегда плохая идея:

  • Любой может заблокировать типы из любого места кода, поэтому у вас нет возможности быть уверенным, что вы не попадете в тупик, не просмотрев весь код.
  • Блокировка типа может даже вызвать взаимоблокировки между доменами приложений. См. Статью Джо Даффи: Не блокируйте объекты с сортировкой за обрез .

Это разрешено, потому что практически нет ограничений на то, что вы можете использовать в качестве объекта блокировки. Другими словами, это не было разрешено специально - просто в платформе .NET нет кода, запрещающего это.

В книге «Отладка приложений Microsoft .NET» есть исходный код правила FxCop DoNotLockOnTypes, которое предупреждает вас, если вы попытаетесь это сделать. (благодаря Кристиану .K)

person Mark Byers    schedule 21.11.2011

arrow_upward
2
arrow_downward

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

Некоторые примеры:

  1. Хейлсберг пожелал (исходная статья: AZ языков программирования: C # - Computerworld), он добавил ссылки на классы C #, не допускающие значения NULL. (Хотелось бы, чтобы он тоже откусил проблему с константой.)
  2. Комитет C ++ облажался с valarray и export, среди множества других мелких и серьезных сожалений.
  3. Шаблоны Java были неудачной работой (OMG, исключение типов!), Разработанной, чтобы избежать изменения виртуальной машины, и к тому времени, когда они поняли, что виртуальная машина все равно должна измениться, было уже слишком поздно производить необходимую переделку.
  4. Правила области видимости Python являются постоянным раздражителем, потому что многочисленные попытки улучшить его не очень помогли (немного, но не сильно).
person Marcelo Cantos    schedule 21.11.2011