Carl Hewitt's actor model (often seen in Erlang, Akka & co.) uses message-passing to communicate between concurrent actors, but doesn't easily allow for state synchronization or dynamic topologies of actors.
Tuple Spaces [https://en.m.wikipedia.org/wiki/Tuple_space] are another paradigm for distributed communication where message tuples are stored into distributed shared "space" and processes can pull messages that match a certain pattern. Very much like how biological cell communicate between each other, which allows for dynamic topologies, but you lose any concept of ordering (message X came before message Y)
The Syndicated Actor model is an attempt at bridging the two ideas to dynamically allow neighbouring actors to coordinate and communicate with each other using something like pub/sub.
I tried to understand Tuple Space a few times but I don't get it.
I understand Erlang and the actor model and how distributed processes work, but what is unique in the Tuple Space aspect? I vaguely recall getting it but it doesn't register for me now.
Maybe it's because Erlang already has pub/sub for every 'thing?'
In Erlang you have a PID and send messages directly to it. The topology is a directed graph.
Process in a tuple space just communicate through shared memory. Messages have no address. And processes can write or pattern match messages from this shared memory space.
Process A:
put({"foo", "bar", 123})
put({"foo", "quux", 456})
Process B, later:
get({"foo", ?x, 123})
# here x = "bar"
Imagine a cell communicating with others by squirting out molecules meant for no one in particular, and having external receptors to match specific other molecules.
This allows actors that have not been designed to work with each other to communicate, just by sharing the same tuple space.
This sounds like you effectively have a global schema (in the DB sense) that all actors have to be consistent with, causing everything to be coupled with everything.
They’re coupled only as far as agreeing on a message format constitutes coupling, which is something you have to do in any actor system anyway. Bigger issue is that tuplespaces tend to be centralized, so it is very much like an app listening to table events in a db, but without a predefined schema. It’s more like pub/sub except one subscribes by message structure, not channel identity.
You also have to prevent unrelated actors from choosing overlapping (conflicting) message formats. In other words, you can’t decide on a new message format without knowledge of all already existing message formats.
This would seem to counter “This allows actors that have not been designed to work with each other to communicate, just by sharing the same tuple space.” Alternatively, I don’t see the big difference to just using separate message queues with pattern-based retrieval. In the end, you always have to design who communicates with who in which format.
The Syndicated Actor Model started off (see dissertation) without any notion of object or actor or entity reference at all. Actors inhabited a single dataspace and there was no baked-in addressing. Since then various developments have led to introduction of entity references (like object references in E). Taken together with dataspaces, this gives you several ways of introducing spacelike separation: you can use different message shapes+patterns, like in "classic" Syndicate or like in tuplespaces; you can use entity-references to have multiple dataspaces on the go at once, forcing isolation that way; or some combination of the two.
Absolutely. A message queue with pattern-based retrieval is a hacky way of getting the first two-thirds of a tuplespace. But, like using a database as a message queue, while it kinda sorta works for the most part, the benefits of the model come in when you start to treat it on its own terms rather than via an encoding. Tuplespaces have a little more to them (not a lot, but some) than just pattern-based retrieval, but some of the research work on them has been focused on appropriate fault-recovery strategies, strategies for sharding and distributing the spaces, etc etc.
Yay! I'm currently working on this (slowly, among many other things). Come visit #syndicate on libera.chat, if you would like to chat about this stuff!
Certainly, as soon as I'm finished reading your dissertation. I've been researching this problem for a while now and it seems you have been a few steps ahead of me all along :)
Carl Hewitt's actor model (often seen in Erlang, Akka & co.) uses message-passing to communicate between concurrent actors, but doesn't easily allow for state synchronization or dynamic topologies of actors.
Tuple Spaces [https://en.m.wikipedia.org/wiki/Tuple_space] are another paradigm for distributed communication where message tuples are stored into distributed shared "space" and processes can pull messages that match a certain pattern. Very much like how biological cell communicate between each other, which allows for dynamic topologies, but you lose any concept of ordering (message X came before message Y)
The Syndicated Actor model is an attempt at bridging the two ideas to dynamically allow neighbouring actors to coordinate and communicate with each other using something like pub/sub.
---
The history page is very much worth reading: https://syndicate-lang.org/about/history/
Here's the author's doctoral thesis: https://syndicate-lang.org/papers/conversational-concurrency...
And SYNIT, a reactive layer for Linux which aims to replace most user-space subsystems with this model: https://synit.org/book/