- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
public void UpdateCollection()
{
object l = new object();
lock (l)
{
// Обновляем коллекцию
}
}
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+110
public void UpdateCollection()
{
object l = new object();
lock (l)
{
// Обновляем коллекцию
}
}
Эксклюзивная блокировка в действии
Что не спасает код от биытия баяном: http://govnokod.ru/11231.
lock (new object()){ }
Ну или так. Чего-уж мелочиться:
Ну а чтобы веселее дебажилось разбавить всё это красивыми хаками типа:
И программа превращается... программа превращается... в однопоточную.
http://govnokod.ru/62
Но ведь, если объект дальше своих полей и приватных структур данных никуда не лезет, то в lock(this) нет абсолютно ничего страшного.
А M$, видимо, решило перестраховаться от индусов, и на всякий случай назвало lock(this) порочной практикой, не указывая в каких именно случаях это зло, а когда можно не бояться ;)
ССЗБ лочиться на внешний монитор
Лок(зис) хуже читается, как мне кажется, потому все и создают специальный локер.
Да ну, нормально он читается :) Локер создают и загоняют в приват чисто ради инкапсуляции, чтобы кроме методов текущего объекта никому не приходила в голову мысль об него лочиться.
Thread Safety: all methods of this class are thread safe and it's instances must not be locked explicitly.
Так и рождается synchronized(concurrentMap)
Можно было даже отдельным говнокодом. Самая соль.
1. Лочатся они эксклюзивно. Всегда.
2. С ними порой такие перожки получаются, любо-дорого посмотреть.
LockFree-коллекции есть? Или LockUnlucky-коллекции? Или LockSeldomForOwner-коллекции?
> перожки получаются, любо-дорого посмотреть.
Какие пирожки?
С кэшем обычно ещё интереснее: данные могут храниться в нескольких структурах одновременно (например, хэш-табличка и LRU-очередь), и синхронизировать нужно сразу несколько объектов.
Собственно сами ребята из MS говорят
"Как правило, рекомендуется избегать блокировки типа public или экземпляров, которыми код не управляет. Распространенные конструкторы lock (this), lock (typeof (MyType)) и lock ("myLock") не соблюдают это правило.
lock (this) может привести к проблеме, если к экземпляру допускается открытый доступ.
lock (typeof (MyType)) может привести к проблеме, если к MyType допускается открытый доступ.
lock("myLock") может привести к проблеме, поскольку любой код в процессе, используя ту же строку, будет совместно использовать ту же блокировку."
Да не воздай доступа к блокировке своей!
Блин, мне страшно юзать софт на фреймворке, если там этот лок по строке распространен.
P.S. Разве lock(ченить) это конструктор? Это же специальный оператор.
P.P.S. Открыл инглиш версию. construct (конструкция) а не constructor там написано. Переводчик у них как всегда ёбнутый на голову ;)
lock(null)
;)
А чем то подход MS очень даже хорош - считай всех тупым быдлом и не будешь разочарован )
А переводят те же пользователи. Чем сложнее статья - тем хреновее переведена. Инфа 100%.
О, а я думал, что там нечто типа промпта старается...
Починил.
Хуевый из меня кеп, да.
Кеп, не забывай подписываться.
object l = new object();
lock (l){}
то ничего не изменится
Программа начнет работать чуточку быстрее из-за меньшего давления на кучу и экономии нескольких инструкций на lock/unlock.
И вообще - не позорьте меня перед Кепом!)))
Это надо этот лок дрочить несколькими тредами. Успешный лок без коллизий практически бесплатен.