I find it useful to use the term "determinate" (determinacy) [1,2] when dealing with concurrent or parallel computing. That puts the focus on equality of outcome (same result), leaving open "deterministic" to mean the exact same sequence of events (schedule).
And it tracks with Determinate Systems, the Nix company. Nix is also focused on giving you the same results every time even if the build process is chaotic inside.
Refreshing post. This is way above my skis. What's interesting to me is that explaining why someone would want deterministic models clarified why someone would want a nondeterministic model. As long as you have a way to make the properties you care about invariant, then you can let the actual implementation be whatever. You also might not want to use a deterministic concurrency model to deal with faults. The point is working around the nondeterminism that the actual implementation experiences. This is a conceit of Erlang, to accept that there are nondeterministic parts of the system, but that the recovery from them is deterministic. You could probably model fault as an input in the Reactor model and then model fault recovery.
What's interesting about the Reactor model is you don't have to accept that combining two deterministic processes automatically makes it nondeterministic. That has to be super useful for real world systems.
I wish the references to Spanner included exactly what aspects; as it's presented here is very hand-wavy. Assuming he means syncing physical clocks with uncertainty windows, those windows have tolerances acceptable for batching together transactions, but probably not every casual dependency within any program. If he means waiting out _logical_ clocks' uncertainty window, isn't that serializing everything?
I'm definitely going to read more about this work to learn more!
I remember deterministic/stable multi threading was an active area in systems research a while back. As I recall it never saw much adoption, most likely due to performance. Haven't watched the full video but will be interesting to see their views on that.
I find it useful to use the term "determinate" (determinacy) [1,2] when dealing with concurrent or parallel computing. That puts the focus on equality of outcome (same result), leaving open "deterministic" to mean the exact same sequence of events (schedule).
[1] As used by Jack Dennis and Arvind: https://cacm.acm.org/opinion/the-resurgence-of-parallelism/#... [2] Originally defined by Karp & Miller: https://www.jstor.org/stable/2946247
And it tracks with Determinate Systems, the Nix company. Nix is also focused on giving you the same results every time even if the build process is chaotic inside.
Refreshing post. This is way above my skis. What's interesting to me is that explaining why someone would want deterministic models clarified why someone would want a nondeterministic model. As long as you have a way to make the properties you care about invariant, then you can let the actual implementation be whatever. You also might not want to use a deterministic concurrency model to deal with faults. The point is working around the nondeterminism that the actual implementation experiences. This is a conceit of Erlang, to accept that there are nondeterministic parts of the system, but that the recovery from them is deterministic. You could probably model fault as an input in the Reactor model and then model fault recovery.
What's interesting about the Reactor model is you don't have to accept that combining two deterministic processes automatically makes it nondeterministic. That has to be super useful for real world systems.
I immediately thought "Edward Lee" when I read the title. And sure...
His seminal paper "The problem with threads" [0] and others inspired [1] a lot.
Boy would I love to see what would have happened if he and Joe Armstrong would have collaborated...
[0] https://ptolemy.berkeley.edu/publications/papers/06/problemw...
[1] https://edms.etas.com/
I wish the references to Spanner included exactly what aspects; as it's presented here is very hand-wavy. Assuming he means syncing physical clocks with uncertainty windows, those windows have tolerances acceptable for batching together transactions, but probably not every casual dependency within any program. If he means waiting out _logical_ clocks' uncertainty window, isn't that serializing everything?
I'm definitely going to read more about this work to learn more!
I remember deterministic/stable multi threading was an active area in systems research a while back. As I recall it never saw much adoption, most likely due to performance. Haven't watched the full video but will be interesting to see their views on that.