Нормально. Но обычно в сиглтоне делают даблчек, чтобы он трейдсейф был
lock тот что в коде не дает потокобезопасности?
обычно вне лока проверяют первый раз, чтобы если объект уже создан, то просто отдать его, а не локаться
Решает. Я тут гугланул расходы на lock, 15ns выглядит норм. Так что пихуй
В целом так делают, но конкретно этот код выглядит достаточно сомнительно. Это мутабельный объект? А дальнейшие мутации защищаются блокировками?
Имхо, double check — не очень нужно в сценариях, когда можно просто сделать статик. (и от статика я бы лично отказался в пользу однократной регистрации в энтрипоинте)
В нем могут изменятся только поля
"глобальные" переменные это плохо
Других варинатов не нашел, нужен буфер для переменных чтобы данные из него в цикле подхватывали статические классы и ViewModel тоже могла их менять
ну как сказал доктор у тебя могут возникнуть проблемы если несколько потоков одновременно будут менять эти переменные
Синглтон с защитой потоков же, нужно еще и поля защищать будет?
если есть вероятность что в поля будет запись из нескольких потоков - то да
Она есть, классы постоянно пишут новые данные
https://docs.microsoft.com/en-us/dotnet/api/system.threading.readerwriterlock?view=net-5.0 можешь что-то такое посмотреть, но в целом тема синхронизации потоков достаточно объемная
Так у тебя защита только при создании инстанса
Буду глядеть про защиту полей)
Ну а ты их изменение защищаешь локом?
В этом и проблема что нет, покачто незнаю каким образом их защищают, буду читать
Стрёмный дизайн приложения, имхо.
Обсуждают сегодня