Есть ли какая-либо гарантия безопасности потока std:: chrono даже при многоядерном контексте?

Во-первых, я предполагаю, что вызов любой функции std:: chrono гарантированно будет потокобезопасным (нет undefined поведение или условия гонки или что-нибудь опасное, если вызвано из разных потоков). Правильно ли я?

Далее, например на окнах есть хорошо известная проблема, связанная с многоядерными процессорами, которые вынуждают некоторые реализации связанных с временем, чтобы заставить конкретное ядро получать информацию о времени.

Что я хочу знать:

Используя std:: chrono, в стандарте, есть ли какая-либо гарантия, что думаю, что проблема не должна появляться?
или определяется реализация
или существует явное отсутствие гарантии, которая подразумевает, что в окнах вам лучше всегда получать время от одного ядра?

Ответ 1

Да, вызовы some_clock::now() из разных потоков должны быть потокобезопасными.

Что касается конкретной проблемы, о которой вы упоминаете в QueryPerformanceCounter, то только Windows API предоставляет аппаратную проблему на некоторых платформах. Другие операционные системы могут или не могут подвергать эту аппаратную проблему коду пользователя.

Что касается стандарта С++, если часы утверждают, что они являются "постоянными часами", тогда он никогда не должен идти назад, поэтому, если в одном потоке есть два чтения, второе никогда не должно возвращать значение раньше, чем во-первых, даже если ОС переключает поток на другой процессор.

Для нестационарных часов (например, std::chrono::system_clock для многих систем) об этом нет никакой гарантии, поскольку внешний агент может в любой момент изменить время.

С моя реализация библиотеки потоков С++ 11 (включая материал std::chrono), реализация позаботится о том, чтобы часы действительно устойчивы. Это накладывает стоимость сверх необработанного вызова QueryPerformanceCounter, чтобы обеспечить синхронизацию, но больше не связывает поток с CPU 0 (который он использовал). Я бы ожидал, что другие реализации также найдут способы обхода этой проблемы.

Требования для постоянных часов приведены в 20.11.3 [time.clock.req] (стандарт С++ 11)

Ответ 2

Я искренне верю, что на этот вопрос полностью отвечает следующее утверждение: нет никакой гарантии, что в реализации не будут ошибки для конкретной платформы. Все это должно работать отлично, но по той или иной причине это не так. Никто не может пообещать вам, что он будет делать то, что вы хотите, но он должен работать.