- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
public sealed class CustomProvider
{
private readonly object _SyncRoot = new object();
public CustomProvider()
{
lock(_SyncRoot)
{-
C# / Говнокод #11989
+141
А вообще, если честно, создание экземпляра класса предка (object) всех классов, чтобы произвести захват критической секции - это так печально. Одному мне эта техника кажется удобной, но странной? Нет чтобы создать класс CriticalSection или что-то такое. А они создают объект совсем не связанный с синхронизацией. Не самодокументированно и тут явно какая-то переголова скрывается при создании объекта, по затратам памяти и системных ресурсов, что в каждый объект на уровне имплементации языка приходится по критической секции добавлять.
Кстати, там как реализована эта критическая секция? Хендл этой критической секции фактически системный ресурс и для него по идеи нужно вызывать Dispose, но это не происходит. Тогда почему этих системных хендлов критической секции хватает, хотя ситуация без Dispose похожа на утечку системных ресурсов?
Если кто подумал про lock(this), то это плохо с точки зрения проектирования класса и его последующего использования, поэтому идея с private _SyncRoot - это правильно. Ведь lock(this) (под this в последнем случае имеется данный экземпляр класса), может использоваться и снаружи класса, что может быть пересинхронизацией.Запостил:
HaskellGovno,
24 Октября 2012
Follow us!
A lock statement of the form
lock (x) ...
where x is an expression of a reference-type, is precisely equivalent to
System.Threading.Monitor.Enter(x);
try {
...
}
finally {
System.Threading.Monitor.Exit(x);
}
"критическая секция" если и реализована, то только в System.Threading.Monitor
Ты хочешь сказать, что на самом деле критическая секция глобальна на весь домен/приложение? Не верю. Думаю они в каждый объект напихали по крит секции.
В .Net реализована своя синхронизация в потоках, с блокировками и ожиданиями но без использования Win32 primitives
Суть в том, что каждый тред может уснуть максимум на одном объекте синхронизации, поэтому нет смысла пихать тяжелые ресурсы в каждый объект.
P.S. Ну и да, там тоже вроде бы используют свои примитивы вместо системных, ибо так шустрее.
ничего не понял. чего печально?
создает наиболее легковесный ссылочный тип. в управляемой куче в sync block'е для него указывается ID текущего треда. и данный тред входит в критическую секцию, а обхект становится флагом выхода.
печально вешать лок в конструкторе, это действительно неправильно и говорит о плохом дизайне.
А лок в конструкторе - да, не комильфо.
странно, ведь массив тоже является объектом
Конструкторы нужны только чтобы выделять память и инициализировать переменные.
А локи и исключения оставьте для методов, в том числе фабричных.
Если только язык не поддерживает RAII
>Что такого критического может случиться на практике
Всё зависит от того зачем хватать лочку. Если просто лок, то ничего.
А если для waitа - чревато исключением и неосвобожденными ресурсами.
http://govnokod.ru/11950#comment156472
А пытаться осбождать ресурсы в конструкторе, при неудачном создании - это верх идиотии.
Что? Тут в данном говнокоде лолк только на поле текущего объекта (не статическое поле). То есть в данном случае конструктор может вызываться параллельно в нескольких потоках для разных объектов. Может я чего не понимаю...
Это вообще бессмысленное говно. Я говорю о сколь-нибудь разумном использовании.
По моему она 0вая
HotSpot следует консервативной рекомендации из JSR-133 Cookbook: «Issue a StoreStore barrier after all stores but before return from any constructor for any class with a final field.»
Другими словами, есть специфичная для хотспота фишка:
// This method (which must be a constructor by the rules of Java)
// wrote a final. The effects of all initializations must be
// committed to memory before any code after the constructor
// publishes the reference to the newly constructor object.
// Rather than wait for the publication, we simply block the
// writes here. Rather than put a barrier on only those writes
// which are required to complete, we force all writes to complete.
То есть, если hotspot обнаруживает в конструкторе запись хотя бы в одно final поле, то он тупо выставляет барьер в конец конструктора и таким образом обеспечивает запись всех полей в конструкторе до записи ссылки на сконструированный объект. Это имеет смысл, чтобы не делать несколько барьеров для нескольких финальных полей.
http://habrahabr.ru/post/143390
Сорри за хабр.
/thread
Это вероятность. Русская рулетка с прицелом в ногу.
Однажды ухитрились так сделать. В конструктор объекта передали ссылку на ее слушатель, аффтар из конструктора дернул у слушателя метод, а слушатель в этом методе дернул объект.
На большинстве Ява-машин прошло, но на некоторых умирало с NullPointerException.
Ну да, поэтому я не понимаю нахрена он тут нужен. Разве что защищать недоконструированный объект от вызова других методов....
Весь прикол в том, что объект должен как-то попасть в статик-поле, что несколько тредов могли его прочесть, следовательно должен быть фабричный метод. Без него никак.
- неявный монитор есть у каждого объекта, в 99% случаев он не используется
- Clonable, обсуждавшийся недавно
- serialization - это вообще треш-угар-содомия: интерфейс Serialazible не объявляет методов, для кастомизации сериализации нужно объявлять магические приватные методы
- можно изменить System.out, присвоить ему null
etc.
Можно ссылку на тред? Разве есть чем заменить Clonable, кроме громоздких клонических фабрик?
Я так понимаю вы про отсутствие кастомной сериализации? А так сериализация нужна. Имхо кастомная не сильно нужна. Думаю, если сильно понадобилась какая-то гиперкастомная, то сериализовать нужно через рефлекшен.
Вот его описание: http://docs.oracle.com/javase/6/docs/api/java/io/Serializable.html.