30 ms·

I immediately thought of ETL when I read this. I don't see how this tuple space concept can work possibly replace robust supervised process management. Also, h

by teilo 8y ago

I immediately thought of ETL when I read this. I don't see how this tuple space concept can work possibly replace robust supervised process management. Also, how is tuple space different than message passing? Somehow a process needs to know what values it is supposed to consume. Something has to manage that, and before you know it, you are passing messages through tuple space and have, essentially, re-invented the wheel.

sago 8y ago
Tuple spaces are simply a way of coordinating between distributed processes. > possibly replace robust supervised process management. No more than message passing replaces supervised process management. A supervisor might use message passing to do its work, or it might use a tuple space, or something else again. It is still a separate thing. > how is tuple space different than message passing Message passing is an example of a shared nothing coordination scheme. For process A to know about some information, process B needs to send a message containing a copy of that information. This is useful, but not always practical. So few systems, even that use message passing, use only this simple form of message passing (more on that below). > Somehow a process needs to know what values it is supposed to consume. Of course. Is is no different regardless of the communication mechanism. Processes need to know what data they need to know. If anything, this is more difficult for message passing: where the sender needs to know what the receiver might need. > Something has to manage that Not necessarily. The processes can just go and read the data from memory. You would be right if you think that sounds like a terrible idea. But unfortunately it was, and still is, more than common. To avoid catastrophe it requires careful use of data locks, mutexes and dances around race conditions and deadlocks. So you are right in thinking that managed approaches are superior. Message passing is one such approach. Tuple spaces are another. > before you know it, you are passing messages through tuple space and have, essentially, re-invented the wheel Partially true, but the opposite is more common. Effectively tuple spaces use a database (of tuple data) as a coordination system, along with one blocking primitive (wait for data). You can, of course, use the data in the database as messages, create some kind of message brokering process, and reinvent message passing. But the opposite is also true. In a complicated system co-ordinated with message passing, you often end up with processes whose job it is purely to hold and be queried for data by multiple consumers/modifiers. Effectively this is coordinating via data. Or re-implementing a cut down tuple space via message passing. When you start to design a 'querying' protocol to allow different processes to access and wait for data in a consistent way, regardless of what that data is, you are very close. This isn't unique to just message passing and tuple spaces. A sufficiently complex (and well designed) program performing parallel computation with threads and semaphores will usually have its own ad hoc reimplementation of both message passing and tuple spaces. Whatever parallel computing formalism you use (and there are others besides these three), you are essentially solving the same problem. It is no surprise that they will begin to resemble each other. Your point seems to assume that message passing is a default. It is certainly the thing that seems to have won the battle for mindshare. But the thesis of the article is that basing a system around a tuple space is a better foundation. And by better I mean that it is easier to code at scale. I am not totally convinced. But I have to say it kind of chimes with my experience. Very large message passing systems become unwieldy, And I have ended up coding something that looks like a tuple space to tame the maze of producers and consumers.
- buckminster 8y ago
  "Any sufficiently complicated message passing system contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of tuple spaces."

by teilo 8y ago

sago 8y ago

Tuple spaces are simply a way of coordinating between distributed processes. > possibly replace robust supervised process management. No more than message passing replaces supervised process management. A supervisor might use message passing to do its work, or it might use a tuple space, or something else again. It is still a separate thing. > how is tuple space different than message passing Message passing is an example of a shared nothing coordination scheme. For process A to know about some information, process B needs to send a message containing a copy of that information. This is useful, but not always practical. So few systems, even that use message passing, use only this simple form of message passing (more on that below). > Somehow a process needs to know what values it is supposed to consume. Of course. Is is no different regardless of the communication mechanism. Processes need to know what data they need to know. If anything, this is more difficult for message passing: where the sender needs to know what the receiver might need. > Something has to manage that Not necessarily. The processes can just go and read the data from memory. You would be right if you think that sounds like a terrible idea. But unfortunately it was, and still is, more than common. To avoid catastrophe it requires careful use of data locks, mutexes and dances around race conditions and deadlocks. So you are right in thinking that managed approaches are superior. Message passing is one such approach. Tuple spaces are another. > before you know it, you are passing messages through tuple space and have, essentially, re-invented the wheel Partially true, but the opposite is more common. Effectively tuple spaces use a database (of tuple data) as a coordination system, along with one blocking primitive (wait for data). You can, of course, use the data in the database as messages, create some kind of message brokering process, and reinvent message passing. But the opposite is also true. In a complicated system co-ordinated with message passing, you often end up with processes whose job it is purely to hold and be queried for data by multiple consumers/modifiers. Effectively this is coordinating via data. Or re-implementing a cut down tuple space via message passing. When you start to design a 'querying' protocol to allow different processes to access and wait for data in a consistent way, regardless of what that data is, you are very close. This isn't unique to just message passing and tuple spaces. A sufficiently complex (and well designed) program performing parallel computation with threads and semaphores will usually have its own ad hoc reimplementation of both message passing and tuple spaces. Whatever parallel computing formalism you use (and there are others besides these three), you are essentially solving the same problem. It is no surprise that they will begin to resemble each other. Your point seems to assume that message passing is a default. It is certainly the thing that seems to have won the battle for mindshare. But the thesis of the article is that basing a system around a tuple space is a better foundation. And by better I mean that it is easier to code at scale. I am not totally convinced. But I have to say it kind of chimes with my experience. Very large message passing systems become unwieldy, And I have ended up coding something that looks like a tuple space to tame the maze of producers and consumers.

buckminster 8y ago
"Any sufficiently complicated message passing system contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of tuple spaces."