|
Потокобезопасный singleton от Ninject
|
|||
---|---|---|---|
#18+
Pu4koffА большего от синглтона и его потокобезопасности и не нужно. Нужно. Обычно еще нужно, чтобы он был ленивым. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2018, 08:15 |
|
Потокобезопасный singleton от Ninject
|
|||
---|---|---|---|
#18+
Сон Веры ПавловныPu4koffА большего от синглтона и его потокобезопасности и не нужно. Нужно. Обычно еще нужно, чтобы он был ленивым. Согласен. В основном из-за этого и стали мудрить с синглтонами, так бы и сидели на статических классах. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2018, 08:59 |
|
Потокобезопасный singleton от Ninject
|
|||
---|---|---|---|
#18+
Сон Веры ПавловныИнициализация поля экземпляра синглтона в статик-конструкторе в общем случае делает его не ленивым Это было до .NET 4 - в 4 поведение поменяли, и статические поля всегда инициализируются лениво. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2018, 09:05 |
|
Потокобезопасный singleton от Ninject
|
|||
---|---|---|---|
#18+
Pu4koffСогласен. В основном из-за этого и стали мудрить с синглтонами, так бы и сидели на статических классах. Далеко не только из-за этого. В статическом классе нельзя использовать полиморфизм, наследование, отделить интерфейс от реализации и т.п. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2018, 09:15 |
|
Потокобезопасный singleton от Ninject
|
|||
---|---|---|---|
#18+
fkthat, Кроме того он сталкивает лбами 2е парадигмы - расшаривать(синглетон) и изолировать(потоки) Поэтому и молчит про задачу) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2018, 10:38 |
|
Потокобезопасный singleton от Ninject
|
|||
---|---|---|---|
#18+
fkthatСон Веры ПавловныИнициализация поля экземпляра синглтона в статик-конструкторе в общем случае делает его не ленивым Это было до .NET 4 - в 4 поведение поменяли, и статические поля всегда инициализируются лениво. Не всегда и не везде. Пример: https://codeblog.jonskeet.uk/2010/01/26/type-initialization-changes-in-net-4-0/ , код из подраздела "Lazy initialization: .NET 4.0". Если скомпилировать в MSVS 2017 в релизе, то вывод будет такой: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
- все вроде бы как положено, ленивая инициализация налицо. Но если собрать в дебаге, то вывод будет уже такой: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
- ленивостью уже и не пахнет. И аналогичный результат будет, если код скомпилировать в MSVS 2010 SP 1 в любой конфигурации. Плюс там же по ссылке см. приписку про implementation-specific in terms of the C# compiler (пример с CachingSideEffect). Дабы обезопасить себя от таких нюансов, люди и пишут синглтоны с использованием Lazy/beforefieldinit/локов. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2018, 14:12 |
|
Потокобезопасный singleton от Ninject
|
|||
---|---|---|---|
#18+
Сон Веры Павловны, Ну х.з., выше уже говорили, что трудно представить ситуацию "не сыграл козырный туз": Pu4koffпри таком варианте: Код: c# 1.
невозможна же ситуация, что instance в разное время будет ссылаться на разные объекты или что инициализатор new Singleton() отработает несколько раз для разных потоков? А большего от синглтона и его потокобезопасности и не нужно. Пока статический конструктор не отработал, никто/ничто ведь не сможет использовать данный тип, верно? По завешению статического конструктора статическое поле будет гарантировано инициализированным. По поводу ленивости, да. Однако, как правило, синглтоны используются в рантайме всегда (если нет, тогда и выбор синглтона - неудачное решение). ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2018, 15:14 |
|
|
start [/forum/topic.php?fid=20&msg=39590603&tid=1399520]: |
0ms |
get settings: |
6ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
41ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
others: | 11ms |
total: | 126ms |
0 / 0 |