Станд.:: строка, thead-безопасная с gcc 4.3?
[anthony-williams],
действительно ли Вы уверены, что не путаете extern объявления шаблона с extern template инстанцирования? Из того, что я вижу, extern template может [только 117] использоваться для явного инстанцирования, не для специализации (который подразумевает неявное инстанцирование). [temp.expl.spec] не упоминает extern ключевое слово:
явная специализация :
template<> объявление
4 ответа
Потоки еще не являются частью стандарта. Но я не думаю, что в настоящее время какой-либо поставщик может обойтись, не сделав std :: string потокобезопасным. Примечание. Существуют разные определения «потокобезопасности», и мое определение может отличаться от вашего. Конечно, нет смысла защищать такой контейнер, как std :: vector, для одновременного доступа по умолчанию, даже если он вам не нужен. Это противоречило бы духу C ++ «не плати за то, что не используешь». Пользователь всегда должен нести ответственность за синхронизацию, если он / она хочет разделить объекты между разными потоками. Проблема здесь в том, использует ли компонент библиотеки некоторые скрытые структуры данных, которые могут привести к гонке данных, даже если «функции применяются к разным объектам» с точки зрения пользователя.
Черновик C ++ 0x (N2960) содержит раздел «Предотвращение гонки данных», который в основном говорит о том, что компоненты библиотеки могут получать доступ к совместно используемым данным, которые скрыты от пользователя, тогда и только тогда, когда они активно избегают возможных гонок данных. Похоже, что реализация std :: basic_string с функцией копирования при записи должна быть такой же безопасной по отношению к многопоточности, как и другая реализация, в которой внутренние данные никогда не передаются другим экземплярам строки.
Я не уверен на 100% в том, действительно ли libstdc ++ уже позаботится об этом. Я думаю, да. Чтобы быть уверенным, ознакомьтесь с документацией
Если вы не против отключить копирование при записи, это может быть лучшим вариантом действий. COW std :: string работает только в том случае, если знает, что копирует другой std :: string, поэтому вы можете заставить его всегда выделять новый блок памяти и делать фактическую копию. Например, этот код:
#include <string>
#include <cstdio>
int main()
{
std::string orig = "I'm the original!";
std::string copy_cow = orig;
std::string copy_mem = orig.c_str();
std::printf("%p %p %p\n", orig.data(),
copy_cow.data(),
copy_mem.data());
}
покажет, что вторая копия (с использованием c_str) предотвращает COW. (Поскольку std :: string видит только голый const char * и не знает, откуда он взялся и каков срок его жизни, поэтому ему нужно создать новую частную копию).
Ни один контейнер STL не является потокобезопасным. Таким образом, библиотека имеет общее назначение (как для использования в однопоточном, так и в многопоточном режиме). В многопоточности вам необходимо добавить механизм синхронизации.
Кажется, что это было исправлено некоторое время назад: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5444 было (закрыто как та же проблема, что и http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5432 , которая была исправлена в 3.1).