Сосредоточимся на программировании
Хорошо
Тогда размышления дальше движутся по такому пути: система получает сигналы и отсылает ответные, информирующие окружение об изменениях в состоянии. Задержки при передаче и обработке сигналов, вообще говоря, могут приводить к тому, что окружение отправляет сигнал, ориентируясь на прежнее состояние системы, тогда как оно может успеть измениться. Например, пользователь сигнализировал "запустить G" (или "запустить F"), и в тот же момент система получила сигнал "A изменилось" - это может ввести в заблуждение пользователя: будет ли произведена операция? И если А изменилось после момента отправки и до момента обработки F - то для какого A будет вычислено F?
Всё это наводит на мысль о том, что любые изменения в системе должны иметь характер транзакций. Система должна отдельно уведомлять о начале и завершении транзакции.
Допустим, все поступающие сообщения помещаются в очередь. Тогда, например, в случае поступления сигнала "изменяется A" уведомление о начале транзакции приводит к тому, что сбрасывается флаг Z1 (и об этом узнаёт UI), а затем уже нужно выполнить собственно модификацию A и закрыть транзакцию.
При этом возможна ситуация, когда системе уже отправлен сигнал "выполнить G", и нельзя быть достоверно уверенным, где данный сигнал находится в настоящий момент (в пути, или в очереди сообщений). Поэтому для успешного старта транзакции требуется обратная связь с источниками сигналов: тогда перед началом транзакции система отправляет уведомление: "сейчас будет изменение, всем стоять" - и собирает ответы "всё, стою, молчу" (в том смысле, что сообщения, пришедшие до этого момента, считаются отправленными в неведении относительно намерений системы, а те, что отправлены позже, могут быть, например, проигнорированы). Соответственно, завершение выглядит подобным образом.
Однако что же делать с сигналами, которые успели наотправлять источники? Думаю, здесь нужна система приоритетов: очевидно, что если данное состояние системы позволяет, скажем, как изменение A, так и вычисление G, то вычислению G нужно отдать приоритет - иначе этот важный процесс может так никогда и не быть выполненным под градом частых изменений A. В то же время, процесс F является менее приоритетным, чем изменения A в том смысле, что в рамках конкретного отсечённого набора сообщений, поступивших до начала транзакции, выгоднее сначала иметь наиболее актуальное A, и лишь затем выполнить F.
