Вопрос по c++, c++11 – Есть ли гарантия безопасности потока std :: chrono даже в многоядерном контексте?

14

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

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

То, что я хочу знать, это:

using std::chrono, in the standard, is there any guarantee that think kind of problem shouldn't appear? or is it implementation defined or is there an explicit absence of guarantee that imply that on windows you'd better get time always from the same core?
И я убрал ответbecause он не отвечает на все вопросы, которые вы спрашиваете. Я чувствовал, что это лучше подходит как комментарий :) jalf
Насколько я понимаю, что проблема возникает только на Windows? В любом случае, зачем убирать свой ответ? Кроме того, это не отвечает на все вопросы, которые я спрашиваю. Klaim
В этой статье базы знаний описаны проблемы с оборудованием. Это не имеет ничего общего с Windows. Та же проблема возникнет наany ОС, которая использует этот аппаратный таймер. И нет, в стандарте C ++ ничего не говорится о том, что «этот класс может вести себя плохо, если вы выполняете свой код на редких неисправных аппаратных средствах». jalf
Посмотрите, что написано в статье базы знаний: «Поведение этой операционной системы разработано специально. Регулировка счетчика производительности необходима, когда операционная система получает ненадежные данные от набора микросхем. Это может произойти на любой ОС. Microsoft просто документирует это, потому что люди встречают его достаточно часто, чтобы оправдать статью в КБ (отчасти потому, что Windows широко используется, а отчасти потому, что она широко используется в играх, где таймеры с высоким разрешением используются чаще) jalf

Ваш Ответ

2   ответа
6

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

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

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

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

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

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

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded Klaim
Error: User Rate Limit Exceededtime_pointError: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
-1

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

Похожие вопросы