есть ли состояние гонки, когда 2 процесса пытаются одновременно прочитать системные часы?

У меня есть 2 процесса (не потока), которые должны одновременно читать системные часы. Для этого в первом процессе используется

QTime::currentTime();

а второй процесс использует

std::chrono::high_resolution_clock::now();

Но когда я читаю соответствующие значения часов, считанные этими двумя процессами, я обнаруживаю, что всегда есть разница в несколько микросекунд. Это потому, что системные часы являются общим ресурсом, поэтому один должен ждать, пока другой закончит чтение? Это потому, что функции, которые считывают системные часы, не совпадают, поэтому разрешение времени не то же самое? (но мне это кажется очень маловероятным... потому что, насколько я понимаю, временное разрешение устанавливается RTC, а не высокоуровневыми API)

Я не использую никаких конкретных «мер» для синхронизации этих 2 процесса. Первый постоянно пытается прочитать системные часы (у него есть время (1)), второй читает системные часы, когда я его запускаю. Итак, поскольку первый процесс всегда пытается прочитать системные часы, я предполагаю, что, вероятно, возникнет «состояние гонки», когда процесс 2 попытается прочитать часы.


race-condition concurrency parallel-processing real-time-clock
person S.E.K.    schedule 14.10.2019    source источник
comment
Как вы координируете два процесса, чтобы начать чтение одновременно?   -  person jingx    schedule 14.10.2019
comment
@jingx я отредактировал свой пост, чтобы ответить на ваш вопрос   -  person S.E.K.    schedule 14.10.2019
comment
Это не имеет ничего общего с тем, что обычно называют состояниями гонки, например, когда один процесс должен ждать, пока другой освободит ресурс. Это просто демонстрирует фактическую невозможность наблюдения двух событий точно в одно и то же время, где точно определяется разрешающей способностью современных компьютерных часов.   -  person High Performance Mark    schedule 14.10.2019
comment
Давайте согласимся, что явный и воспроизводимый эксперимент, сформулированный в рамках MCVE, — это правильный путь, а не нечеткие, самоуверенные гипотезы — так что лучше, чем говорить Я думаю, что, вероятно, будут... определить тест, возможно, написанный прямо на общедоступной платформе, например на godbolt.org/z /ZVnO6R или аналогично на tio.run/# (имея более 680 компилируемых/интерпретируемых языков) --- и мы все начинаем находить общий язык для проверки { [PASS] | [НЕУДАЧА] }-сценарий и продвигать любое улучшенное решение исходной проблемы --- это справедливо, если оно будет и воспроизводимым, и количественным, не так ли?   -  person user3666197    schedule 14.10.2019

Ответы (1)


arrow_upward
0
arrow_downward

Существует только состояние гонки в том смысле, что вы не можете предсказать, какой процесс сообщит о более раннем времени или сообщит об одном и том же времени. (Почти) одновременное считывание часов не причиняет никакого вреда. Оба отчета будут точными в пределах способности ОС предоставлять информацию. В зависимости от ОС и аппаратного обеспечения два процесса могут или не могут сообщать об одном и том же времени.

Это может быть или не быть общим ресурсом. Это могут быть даже не одни и те же часы под капотом. std::chrono::high_resolution_clock обычно представляет собой typedef либо std::chrono::steady_clock, либо std::chrono::system_clock, и какой из них зависит от платформы. В macOS/iOS/watchOS high_resolution_clock представляет собой число от typedef до steady_clock и отсчитывает наносекунды с момента загрузки системы. Эта мера не имеет отношения к времени суток или дате в календаре.

Описание разницы между steady_clock и system_clock есть здесь.

person Howard Hinnant    schedule 14.10.2019