4 ms·
Oz's declarative concurrency is worth taking a look at. In Oz, a thread implicitly goes into sleep or wake up on data dependency. for example, declare
by CodeArtisan 8y ago
Oz's declarative concurrency is worth taking a look at. In Oz, a thread implicitly goes into sleep or wake up on data dependency. for example,
declare
FOO BAR % FOO and BAR are not bound to any value yet.
in
thread
{print FOO} % the thread blocks here until FOO is bound to a value.
BAR = 456 % Binds BAR which wake up any thread waiting for it.
end
thread
FOO = 132 % Binds FOO which wake up any thread waiting for it.
{print BAR} % the thread blocks here until BAR is bound to a value.
end
Because of this, ordering of operations is easy.
- TeMPOraL 8y agoThis sounds like an easy recipe for race conditions. Consider: declare FOO BAR % FOO and BAR are not bound to any value yet. in thread {print FOO} % the thread blocks here until FOO is bound to a value. BAR = 456 % Binds BAR which wake up any thread waiting for it. end thread {print BAR} % the thread blocks here until BAR is bound to a value. FOO = 132 % Binds FOO which wake up any thread waiting for it. end I swapped the instructions in the second thread. Does Oz detect that, or otherwise protect programmer from such mistakes?
- CodeArtisan 8y agoIt would deadlock but there is a debugger that shows the state of any thread and where it is blocked.
- smaddox 8y agoSo it's race free.... If you test every single possible system state, and remove all the race conditions. No thanks.
- ghkbrew 8y agoA race condition is a situation where the result depends on the ordering/interweaving of threads. And that example isn't actually one. It's a deadlock which are also bad but much more deterministic and easier to debug.
- raattgift 8y agoIf that's the complete program or alternatively if it's the entire scope for the FOO and BAR variables such that the language guarantees no other thread (or process or anything else) may mutate or even access FOO or BAR, then the implementation should throw an error saying as much, the moment the scope is left (e.g. by reaching end-of-input). However, if one is still free to do the moral equivalent of BAR = 1 or FOO = argc in a third thread, or even at compile/link time, then why should it a mistake to have these two threads blocking on such a (possible) event?
- radarsat1 8y agoJust a guess, but it sounds like it could be detected via static dependency analysis and the compiler could throw an error.