Hacker News Reader

Comment by JackFr | Hacker News Reader

I remember when tuple spaces were the new hotness and going to a presentation from GigaSpaces at my local JUG.

And now I can't even remember the problem they solve or any potential use cases. Weird.

Primary problem: Distribute work on heterogenous data across a cluster of heterogenous processes. Add new processes (either additional workers or additional capabilities) by attaching them to the existing shared tuple space. Add new data by wrapping it into a tuple and tossing it into the pile. Add a processor for the new data by having it search for a pattern that picks up the new tuple.

Similar concept behind message queue based systems, service oriented architecture, and many, many others. Though more pull-based than push-based. You wouldn't explicitly launch a process, you have a process that sits around waiting to for a tuple to show up and then takes/copies it and does the work.

> Add new data by wrapping it into a tuple and tossing it into the pile

In David Gelernter's original work, it's not just data. In Linda, it's possible to put Objects in, which are little executable (`eval` in Linda terms) which a processor can manipulate through whatever interface the tuple type exposes.

That does not sound very secure.

Also, what's to stop another processor "finding" the Object before the intended recipient?

1. Just bare like that, it's not. Unless, of course, the object requires a key to allow a processor to execute it. See for example Capability-Based Access Control

2. In TupleWorld, there's no concept of "the" intended recipient. The tuple's properties determine what kind of processor would match. If those properties happen to only match a single processor, you'd get that 1:1 mapping you want, but that's missing the point of tuple spaces.

Just coordinating the 1:1 mapping I might want is fraught with challenges. Network delays, out-of-order execution, stampeding herd situations, poison objects, processors crashing (or being rebooted) at random times... I'm not seeing the benefit of a "bag" of objects to be processed whenever by whoever or whatever.

Perhaps this is attempting to solve a problem I've not come across. While it sounds interesting, I'm not sure I see the benefit? (Probably me just being short-sighted).

It's a way of doing massively parallel computations in a scatter/gather system. I suggest looking up the paper "Linda in Context. I'd provide a link but I'm on my phone.

Here you go (not on mobile):

https://dl.acm.org/doi/10.1145/63334.63337 (free access)

Also worth reading are the "Linda Letters" from Communications of the ACM, October 1989, vol 32, no 10, p 1244. I found an excerpt at https://web.archive.org/web/20160901000000*/https://www.cyph..., starting on page 4 of the PDF

Somehow this model works to build complex organisms in embryology...

Still have a problem with viruses, though...

Also, on "poison objects". We execute Javascript all the time in our browsers. Sandboxing and other measures keep the executable objects from exploiting our computers. It's imperfect, of course, and there are still exploits, but that's the general approach. Things like out-of-order execution and so forth require careful parallel design, but that's pretty much the bread-and-butter of things like SETI@Home

This exactly. Sadly the idea went through a low pass filter and just became a way to pass around dumb data objects.

It's not unlike the Blackboard system pattern (https://en.wikipedia.org/wiki/Blackboard_system#Metaphor) in that respect, but Gelertner had something more ambitious in mind.

Honestly, I suspect the other, fancier parts of the idea were more like a solution in search of a problem.

The way I think about it is as the ultimate decoupling between producer and consumer. Bundling producer and consumer together into one unit spatially couples them. But even if the producer runs as a separate service that waits for requests from the consumer the interaction is still temporally coupled.

By having the producer gradually update the responses to all possible queries to a tuple space, completely on its own schedule, there is not even temporal coupling between it and the consumer.

Reply on news.ycombinator.com