Моё скромное IMHO — отлично реализованы и double-lock и Рихтеров. Именно потому, что если в языке/библиотеках к нему есть потоки, то должны быть и Lock, и атомарный перенос. А значит — будет не проблема перенести эти реализации куда-нибудь на Java.
— static класс невозможно от чего-то унаследовать — а значит, не получится собрать абстрактную фабрику (фабрики рекомендуют объявлять синглтонами ещё в самой первой книжке).
— когда выполнится static-конструктор — никто не знает. Вроде бы «где-то в начале». К тому же, для ASP.Net-приложений может быть актуальным совмещение фабрика по производству синглтонов :) — по синглтону на сессию. Ведь в ASP.Net статичные переменный глобальны для всего приложения.
— Когда падает конструктор статического класса — всё падает. Когда падает конструктор синглтона — падает только функция, которая неосторожно его вызвала
— Невозможность засунуть в статичный класс счётчик состояний (например, чтобы можно было откатить его к предыдущим настройкам).
— static класс невозможно от чего-то унаследовать — а значит, не получится собрать абстрактную фабрику (фабрики рекомендуют объявлять синглтонами ещё в самой первой книжке).
— когда выполнится static-конструктор — никто не знает. Вроде бы «где-то в начале». К тому же, для ASP.Net-приложений может быть актуальным совмещение фабрика по производству синглтонов :) — по синглтону на сессию. Ведь в ASP.Net статичные переменный глобальны для всего приложения.
— Когда падает конструктор статического класса — всё падает. Когда падает конструктор синглтона — падает только функция, которая неосторожно его вызвала
— Невозможность засунуть в статичный класс счётчик состояний (например, чтобы можно было откатить его к предыдущим настройкам).
Я тоже не вижу особых проблем с double lock-ом — всё-таки все его недостатки уже успели устареть. Хотя и с Рихтером согласен — try-catch в этом случае не нужен.
Другое дело, что варианты с readonly и nested-классом расползлись по уйме книг и теперь много кто уверен, что именно «хаками» такое и надо писать.
А как думаете, не лучше ли вместо Lock писать нативный Monitor.Enter? Я тут больше ко мнению Jeffry Richter'а склоняюсь — сгенерированный комплятором try здесь а) тормозит б) если отвалится — уже не поможет.
Всё вы правильно поняли :). Поток создаёт temp, а потом _атомарно_ переносит его через Interlocked.CompareExchange. В итоге следующий поток уже не может ничего записать — Interlocked же.
Последний вариант я взял из CLR via C# by Jeffry Richter, последняя, 29-я глава. Там довольно подробно объясняется, почему так лучше.
Моё скромное IMHO — отлично реализованы и double-lock и Рихтеров. Именно потому, что если в языке/библиотеках к нему есть потоки, то должны быть и Lock, и атомарный перенос. А значит — будет не проблема перенести эти реализации куда-нибудь на Java.
— static класс невозможно от чего-то унаследовать — а значит, не получится собрать абстрактную фабрику (фабрики рекомендуют объявлять синглтонами ещё в самой первой книжке).
— когда выполнится static-конструктор — никто не знает. Вроде бы «где-то в начале». К тому же, для ASP.Net-приложений может быть актуальным совмещение фабрика по производству синглтонов :) — по синглтону на сессию. Ведь в ASP.Net статичные переменный глобальны для всего приложения.
— Когда падает конструктор статического класса — всё падает. Когда падает конструктор синглтона — падает только функция, которая неосторожно его вызвала
— Невозможность засунуть в статичный класс счётчик состояний (например, чтобы можно было откатить его к предыдущим настройкам).
— static класс невозможно от чего-то унаследовать — а значит, не получится собрать абстрактную фабрику (фабрики рекомендуют объявлять синглтонами ещё в самой первой книжке).
— когда выполнится static-конструктор — никто не знает. Вроде бы «где-то в начале». К тому же, для ASP.Net-приложений может быть актуальным совмещение фабрика по производству синглтонов :) — по синглтону на сессию. Ведь в ASP.Net статичные переменный глобальны для всего приложения.
— Когда падает конструктор статического класса — всё падает. Когда падает конструктор синглтона — падает только функция, которая неосторожно его вызвала
— Невозможность засунуть в статичный класс счётчик состояний (например, чтобы можно было откатить его к предыдущим настройкам).
Другое дело, что варианты с readonly и nested-классом расползлись по уйме книг и теперь много кто уверен, что именно «хаками» такое и надо писать.
Последний вариант я взял из CLR via C# by Jeffry Richter, последняя, 29-я глава. Там довольно подробно объясняется, почему так лучше.