Здравствуйте, Bell, Вы писали:
B>Здравствуйте, LuciferMoscow, Вы писали: LM>>Безопасен ли такой код в многопоточной среде: B>Нет. Подробности поищи сам — такой вопрос проскакивал не один раз.
Ключевые слова?
Здравствуйте, LuciferMoscow, Вы писали:
LM>Здравствуйте, Bell, Вы писали:
B>>Здравствуйте, LuciferMoscow, Вы писали: LM>>>Ключевые слова? B>>Да хоть вот эти: B>>static + потоко LM>грустно, блин.
LM>А как это сделать threadsafety для non POD типов?(не нашел честно)
Сразу скажу:
Здравствуйте, LuciferMoscow, Вы писали:
LM>Здравствуйте, Bell, Вы писали:
B>>Здравствуйте, LuciferMoscow, Вы писали: LM>>>Безопасен ли такой код в многопоточной среде: B>>Нет. Подробности поищи сам — такой вопрос проскакивал не один раз. LM>Ключевые слова?
Просто конструкция
static SomeSingleton Singl;
не является атомарной
Здравствуйте, LuciferMoscow, Вы писали:
LM>Здравствуйте, Bell, Вы писали:
B>>Здравствуйте, LuciferMoscow, Вы писали: LM>>>Ключевые слова? B>>Да хоть вот эти: B>>static + потоко LM>грустно, блин.
LM>А как это сделать threadsafety для non POD типов?(не нашел честно)
Обычная синхронизация поможет
Здравствуйте, LuciferMoscow, Вы писали:
LM>Здравствуйте, LuciferMoscow, Вы писали:
LM>>Здравствуйте, Bell, Вы писали:
B>>>Здравствуйте, LuciferMoscow, Вы писали: LM>>>>Ключевые слова? B>>>Да хоть вот эти: B>>>static + потоко LM>>грустно, блин.
LM>>А как это сделать threadsafety для non POD типов?(не нашел честно) LM>Сразу скажу:
LM>
LM>Не предлагать.
Дело в том, что стандарт ничего не говорит про многопоточность, так что мы не можем
полагаться, что компилятор сгенерирует потокобезопасный код для static
Поэтому заботиться о потокобезопасности должен ты сам.
И потому обойтись без мютексов тебе не получится.
Здравствуйте, avbochagov, Вы писали:
A>Для подсказки кину такую фамилию — Александреску. У него эта тема разжевана так, что потом вопросов не остаеться.
The pattern is usually unsafe on modern computer hardware and/or optimizing compilers.
One of the dangers of using double-checked locking is that it will often appear to work: it is not easy to distinguish between a correct implementation of the technique and one that has subtle problems. Depending on the hardware platform, the compiler, the interleaving of threads by the scheduler and the nature of other concurrent system activity, failures resulting from an incorrect implementation of double-checking locking may only occur intermittently. Reproducing the failures can be difficult.
стандарт частично решает проблему использованием
volatile sig_atomic_t integer
Type of object that can be modified as atomic entity, even in presence of asynchronous interrupts;
однако только теоретически. На практике я бы поостерёгся решения, целиком построенного на соответствии оптимизатора компилятора и стандарта.
kalsarikännit
Re: static && multithreading
От:
Аноним
Дата:
21.10.05 14:38
Оценка:
Здравствуйте, LuciferMoscow, Вы писали:
LM>Безопасен ли такой код в многопоточной среде:
Уже ответили, что нет...
С сингелтонами лучше их сначала явно проиницировать,
а только потом запустить потоки.
Убивание сингелтонов — тоже нетривиальная задача,
даже в однопоточной среде.
Здравствуйте, LuciferMoscow, Вы писали:
LM>Безопасен ли такой код в многопоточной среде:
[...]
GCC 4.0 по умолчанию синхронизирует создание статических-на-уровне-функции объектов:
The compiler now uses the library interface specified by the C++ ABI for thread-safe initialization of function-scope static variables. Most users should leave this alone, but embedded programmers may want to disable this by specifying -fno-threadsafe-statics for a small savings in code size.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
It's kind of fun to do the impossible (Walt Disney)
А что, если заставить статические данные инициализироваться на ранней стадии, в контексте главного потока до входа в main()?
Т.е. сделать объект (или ссылку на него) глобальным.
Data& init_instance()
{
static Data data;
// медленно и печально работаем
.....
return data;
}
Data& instance = init_instance();
Или это противоречит логике работы (временной диаграмме)?