Два типа событий
2023-12-08 13:20![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Я тут по работе взялся переделать некий симулятор дискретного времени на multi-threading. Приходится переосмысливать саму организацию цикла выполнения и очереди событий. Пришёл к выводу, что события должны быть двух типов: одни выполняются в начале цикла, другие в конце цикла. Поясню картинкой.

Представим, что мы прогнали симулятор до останова #24 (модельное время равно 24), а затем дали команду выполнить ещё один цикл (до останова #25). Что при этом произойдёт?
Из очереди событий выполнятся некоторые действия (типа A), затем счётчик модельного времени увеличится на единицу, после этого выполнятся ещё какие-то действия (типа B).
События типа A - это "неразрушающие" действия, типа чтения из памяти. Они не изменяют состояние моделируемого объекта. События типа B - изменение состояния, например запись в память.
По опыту, события A обычно начинают некоторый процесс, растянутый по времени. События B завершают его. К примеру, рассмотрим выполнение оператора "x += 1". Оно состоит из двух событий:
Почему-то нигде раньше, ни в коде, ни в литературе я не встречал такой организации очереди событий.

Представим, что мы прогнали симулятор до останова #24 (модельное время равно 24), а затем дали команду выполнить ещё один цикл (до останова #25). Что при этом произойдёт?
Из очереди событий выполнятся некоторые действия (типа A), затем счётчик модельного времени увеличится на единицу, после этого выполнятся ещё какие-то действия (типа B).
События типа A - это "неразрушающие" действия, типа чтения из памяти. Они не изменяют состояние моделируемого объекта. События типа B - изменение состояния, например запись в память.
По опыту, события A обычно начинают некоторый процесс, растянутый по времени. События B завершают его. К примеру, рассмотрим выполнение оператора "x += 1". Оно состоит из двух событий:
- чтение значения x - событие типа A
- запись значения x+1 - событие типа B
Почему-то нигде раньше, ни в коде, ни в литературе я не встречал такой организации очереди событий.
no subject
Date: 2023-12-08 22:53 (UTC)no subject
Date: 2023-12-08 22:59 (UTC)no subject
Date: 2023-12-09 18:01 (UTC)Я думаю, что вы потрясёте это еще немного, выяснится, что нужно еще и в середине цикла. В общем, выполнять в порядке модельного времени.
no subject
Date: 2023-12-09 19:08 (UTC)no subject
Date: 2023-12-08 23:34 (UTC)no subject
Date: 2023-12-09 19:09 (UTC)no subject
Date: 2023-12-10 13:36 (UTC)no subject
Date: 2023-12-19 18:22 (UTC)no subject
Date: 2023-12-08 23:40 (UTC)Эмулятор машины времени?
no subject
Date: 2023-12-09 19:10 (UTC)no subject
Date: 2023-12-10 10:44 (UTC)Я к тому, что точно -, а не +?
А то звучит как "приходите вчера".
no subject
Date: 2023-12-08 23:42 (UTC)Мне кажется, что раз я мало что понял, вы либо слишком сильную абстракцию сделали - либо вам нужно понижать гранулярность. Например, если раньше вы оперировали миллисекундами - то надо перейти на наносекунды.
> дискретного времени на multi-threading
У меня тоже что-то подобное было: сплошные подводные камни.
Уже на этапе работы с часами начинаются проблемы. Например, ntp может двигать время назад. вроде не должен, но иногда делает, например когда високосная секунда прилетает, то ntp переставлял таймер на 1секуну назад. (Щас наверное это уже исправили)
Или например, в старых процах в каждом ядре был свой счетчик тактов, и поскольку каждое ядро имеет свой генератор, то со временем показания тактовых счетчиков у ядер расходятся. А потом операционка перебрасывает задачу на другое ядро. Запрашивается время - и время получается меньше, чем было. (К счастью, потом это починили)
Ну и всякие такое, щас уже не вспомнишь.
сколько ни работаю с часами - такого, чтобы совсем без подводных камней никогда небыло.
Еще бывает, что по ntp приходили пакеты некорректные - и часам крышу срывало полностью.
no subject
Date: 2023-12-09 19:13 (UTC)Понижение гранулярности не помогает. Если у вас проблемы между тактами #24 и #25, то переход с миллисекунд на наносекунды приведет к тем же проблемам между #24000 и #24001. Или между #24999 и #25000. Или где-то ещё. Дискретное время, оно такое.
no subject
Date: 2023-12-09 00:01 (UTC)no subject
Date: 2023-12-09 19:00 (UTC)no subject
Date: 2023-12-09 03:22 (UTC)Кстати, https://dl.acm.org/doi/pdf/10.1145/360715.360758 (хотя там скорее про структуры данных)
no subject
Date: 2023-12-09 19:19 (UTC)Любопытная статья. Выходит, в 1975 году народ активно интересовался эффективным представлением очереди событий. Нынче оно реализуется в Си++ стандартным std::set с несложной функцией сравнения. Недавно я показывал: https://vak.dreamwidth.org/1105670.html
no subject
Date: 2023-12-09 08:44 (UTC)no subject
Date: 2023-12-09 19:20 (UTC)Честно говоря, не вижу тут автоматов Мили и Мура. 😀
no subject
Date: 2023-12-09 20:12 (UTC)no subject
Date: 2023-12-09 20:42 (UTC)no subject
Date: 2023-12-09 20:59 (UTC)