Здравствуйте, AleksandrN, Вы писали:
AN>Есть несколько объектов, объявленных как static thread_local?
Да, синглтон на каждый тред свой.
AN>Вместо нескольких таких объектов, сделать один, который будет обёрткой над этими объектами и инициализировать и разрушать остальные в нужном порядке.
Тогда этот объект придётся завести под мьютекс, чтобы в процессе доступа какой-то другой процесс не убил там чего-то или не добавил. А для меня синхронизация — непозволительная роскошь.
AN>А лучше подумать, как избавится от ситуации, когда к объекту, объявленному как thread static, обращаются не временные объекты, а другие статические объекты.
Никак не избавиться. Эта система слишком общая, чтобы её можно было чем-то принудительно ограничить. Представьте себе, например, логгер. Вы можете заставить кого-то запретить запись в лог в любой момент, когда ему это хочется?
Re[5]: Продлить жизнь статической переменной в функции
Здравствуйте, Went, Вы писали:
W>Тогда этот объект придётся завести под мьютекс, чтобы в процессе доступа какой-то другой процесс не убил там чего-то или не добавил. А для меня синхронизация — непозволительная роскошь.
Т.е. — к переменным, объявленным как static thread_local могут обращаться другие потоки? Каким образом это сделано и почему обращение к ним без синхронизации?
W>Никак не избавиться. Эта система слишком общая, чтобы её можно было чем-то принудительно ограничить. Представьте себе, например, логгер. Вы можете заставить кого-то запретить запись в лог в любой момент, когда ему это хочется?
Сделать одну точку выхода и закрывать лог после того, как прекратили работу все, кто может в него писать.
Re[6]: Продлить жизнь статической переменной в функции
Здравствуйте, AleksandrN, Вы писали:
AN>Т.е. — к переменным, объявленным как static thread_local могут обращаться другие потоки? Каким образом это сделано и почему обращение к ним без синхронизации?
Объект создается в static thread_local коллекции одного потока, но потом передаётся для пользования в другой поток. И тот поток решает его убить. Почему без синхронизации — потому что синхронизация дорого, не дело, когда 75% от времени алгоритмов жрут мьютексы.
AN>Сделать одну точку выхода и закрывать лог после того, как прекратили работу все, кто может в него писать.
Я же говорю, что ограничить нельзя. Нет никакой "одной точки выхода". Это, по сути, библиотека, которую кто как захочет, так будет пользовать.
В любом случае, изначальный вопрос (продление жизни) я решил. Как писал выше — заложился на то, что компилятор не будет затирать мусором статические переменные потока до того, как последний статический элемент этого потока полностью будет разрушен (тавтология получается немного). А для решения вопроса блокировок сделал хитрый алгоритм на смеси блокирующих и неблокирующих подходов. Вроде работает. Только подразумевает атомарность записи указателя в память.
