в прицнипе "потеря апдейтов" может происходить, stm не гарантирует что каждый ридер будет пробужен, чтобы увидеть каждый аптейт TVar-ов, на которых он сделал retry

то есть, как я понимаю, единственный способ гарантированно увидеть все апдейты — это писать из в TChan

+

хм, а почему не гарантирует?

Или queue, не важно

ну или писать в TChan что-то, что сигнализирует об апдейте

А с чего бы должен?

мол если придет новый апдейт, то он возьмет новый вместо предыдущего?

да, понял

это логично

Мы же читаем не апдейт, а новое состояние, какое есть в текущий момент времени

У Дункана в его докладе это было важной фичей

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

но это значит, что другие ридеры могут просто не успеть прочитать значение, пока будут читать другой твар скажем

или они по очереди выполняются?

Все сразу

если у меня будет два одинаковых треда, каждый будет читать и сразу обновлять значение, то всегда будет работать только первый, а второй вечно ретраится?

ок

Да, могут не успеть прочитать обновление, порядок пробуждений и работы в stm не специфицирован, by design

не знаю, но думаю, что поскольку retry может происходить на каком угодно user defined условии, нарантировать что-то в общем случае невозможно. Точнее _наверное_ возможно, но это будет неэффективно или дедлокаться или еще чего-то такое. Поэтому retry — это просто "попробуй еще раз, если ситуация поменялась" и неважно, что она поменялась еще 100 раз с тех пор. Собственно, поэтому и нет fairness и треды могут голодать бесконечно и все такое.

нет, ФП легче использовать с immutability