отсутствие первой проверки в паттерне double check
От: conceal_blaze  
Дата: 29.09.10 06:12
Оценка:
Добрый день.
В классе ConfigurationManager.GetSection() в одном из вызываемых методов обнаружил, что у конструкции
if(m_instance == null)
{
lock(m_lock)
{
if(m_instance == null)
{
...
}
}
}
отсутствует первая проверка.
Всегда думал что оператор lock очень ресурсозатратен, поэтому и применяется первая проверка.
Может подскажет кто причину отсутствия первого условия, а так же как это может сказаться на производитеьлности приложения?
Если это уже обсуждалось или описано в какой-либо статье, буду благодарен за ссылку...
Re: отсутствие первой проверки в паттерне double check
От: Mab Россия http://shade.msu.ru/~mab
Дата: 29.09.10 06:17
Оценка:
Здравствуйте, conceal_blaze, Вы писали:

Ну раз нет, то значит это не DCL. Предполагается, что этот метод не будут дергать часто, так что какая разница, что там внутри.
Re: отсутствие первой проверки в паттерне double check
От: Александр Кузнецов Россия  
Дата: 29.09.10 06:20
Оценка:
Здравствуйте, conceal_blaze, Вы писали:

_>Может подскажет кто причину отсутствия первого условия, а так же как это может сказаться на производитеьлности приложения?


Как самый первый вариант — лажа разработчика (если библиотеки подробно посмотреть рефлектором, там много разных "неочевидных решений" есть — в MS код тоже смертные пишут ). С учетом того, что обычно конфиг не читают в цикле, потеря производительности критической не будет.
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) Макконнелл, "Совершенный код".
Re[2]: отсутствие первой проверки в паттерне double check
От: conceal_blaze  
Дата: 29.09.10 06:37
Оценка:
Здравствуйте, Александр Кузнецов, Вы писали:

АК>Как самый первый вариант — лажа разработчика (если библиотеки подробно посмотреть рефлектором, там много разных "неочевидных решений" есть — в MS код тоже смертные пишут ). С учетом того, что обычно конфиг не читают в цикле, потеря производительности критической не будет.


Самое интересно что профилировщик не показывает падения производительности на lock, так что есть мысль что так было реализовано специально.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.