I built a tuple space implementation a few years ago. I came to the conclusion that the filter predicates were functionally equivalent to delayed RPC, aka task queues, and occasionally even publish/subscribe. It's at that point that I got bored and left the code to (essentially) rot.
I now use task queues on a daily basis to process countless non-realtime tasks. It's a much more straightforward metaphor for what you actually want to do, and without altering the paradigm, allows you to do practically useful things (prioritizing, deadlines, retries, etc.)
It is a useful conceptual model, but mostly as a way to pull people away from the MPI/PVM/threads/processes lock-step/locking parallel concurrency models.
Has anyone successfully used this for anything significant? As I post this there's only a couple of people posting about how either they tried but it didn't work out well enough, or they just played with it in school without any code.
It strikes me as having the same problems as RDF storage; precisely because the model is so general, there's nothing for optimizations to grab on to and optimize on. Your database has to stand ready to do anything equally. The core of database optimization is, when you really get down to it, working out how to tell your database which things you really want and what you will never care about, as in "This table has twenty columns but I will only query on name and phone number". In practice, limitations aren't always just there because of a lack of imagination or insufficient computer science education (though that does happen), sometimes they're there because you can't get any performance without them.
I did a post-grad project using JavaSpaces and prolog to do automated refactoring in Java back in the late 90's. The JavaSpaces implementation was so terrible that it was hard to get anything done. Great idea, but poor execution in Java probably killed Jini and JavaSpaces (and any hope of it going mainstream).
We used JavaSpaces/Jini in an EMRS system during the same period(and also tried GigaSpaces which was best impl) called Frontiers which was at some point used at many hospitals on both coasts.
It did make things very flexible as in we knew we could just start ripping pieces out of the system during testing to make sure every piece was completely autonomous and definitely redundant with data. Also had "agents" in self contained "hot reloadable" classes because we learned about the discarded classloader trick. Man, learned so much fun/crazy stuff at that job.
Yeah, I've used Rinda for load balancing across small numbers of machines before. It's a couple of screens of ruby in total to get that working, which I was astonished by.
Btw, Linda's name was "inspired" by Ada. Except instead of using a famous female mathematician (Ada Lovelace), he used a famous female pornstar (Linda Lovelace): http://en.wikipedia.org/wiki/Linda_Lovelace
Tuplespace is all about lookups/publish/subscribe on filters on the tuples. For the vast majority of the time, filters are of the form of (<string>, <type>, ...) or (<string>, <value>, ...) . You don't need to use skip lists (or binary trees generally) for that, you can use nested hash tables on the prefix/suffix of the tuples. Then you get O(len(filters)) instead of O(log(size of tuple space)). Trust me when I say that using hashes of filters is a lot faster.
Also, see my higher-ranked post about why I stopped using tuple spaces.
We use GigaSpaces (a commercial implementation of JavaSpaces that can also be used from a .NET environment) where I work, but we're underutilizing its capabilities terribly. The product itself apparently has a healthy niche in the financial services sector.
I laughed when I read you comment because I find my message queues always seem to want to morph into these Tuple Spaces -- seriously. I never knew there was a name here, just that I seem to frequently want some more generic properties matching nicely to the this whole pattern.
Biggest issue I had was the idea of communicating data through the actual space which is why message based protocols that handle direct function/method invocation on take are so much easier to deal with and not worry about performance issues.
It sure as shot was fun to play with it in a big enterprise environment for a while though. =)
Saw a cool presentation by Gary Warren King on AllegroGraph (a lisp based tripple store) last year. It stores RDF tripples, which seem to be a pretty powerful tool for modeling semantic relationships.
I did Linda in the university, during the Concurrent Programming course. It was lots of fun, even though we never actually wrote a line of code in any place other than the blackboard... It is sad that the model did not take off.
I'd say they compare closely to either Redis' hash or unsorted list implementations. It's hard to say exactly since the operations tuples support are similar to both.
This, of course, ignores the complexity of operations on Redis hash and list objects. I don't think any tuple space implementation has a known complexity for get or put operations.
I now use task queues on a daily basis to process countless non-realtime tasks. It's a much more straightforward metaphor for what you actually want to do, and without altering the paradigm, allows you to do practically useful things (prioritizing, deadlines, retries, etc.)
It is a useful conceptual model, but mostly as a way to pull people away from the MPI/PVM/threads/processes lock-step/locking parallel concurrency models.