small medium large xlarge

Avatar_pragsmall
25 Mar 2014, 18:58
Joel VanderWerf (2 posts)

Paul,

It’s interesting that you decided to include CSP instead of tuplespaces. The reasons for including CSP are well stated and justified. Would you consider including some discussion of the viability of the tuplespace model, its potential applications, and suggestions for futher reading?

My view is that tuplespaces have been neglected in the resurgence of concurrent programming, and that they can benefit from some recent ideas in distributed transactional databases. (If you’re interested in details: https://github.com/vjoel/tupelo.)

I’m enjoying the book so far. Having each model presented in the same context, by the same author, makes it so much easier to cut through the hype, see where the use cases of one model overlap with another, and understand the tradeoffs in those cases.

Icon_pragsmall
26 Mar 2014, 12:56
Paul Butcher (34 posts)

Joel,

I have a soft spot for tuple spaces as they were the subject of my PhD back in the early 90s :-) I wasn’t aware of Tupelo - thanks for the pointer.

I’m not sure if you’ve seen it yet, but the final draft does include a brief mention of Tuple Spaces together with a couple of pointers for further reading. I’ll certainly add a link to Tupelo.

Although there’s not room for it to be expanded a great deal, if there are any particular aspects you feel it would be good to mention, I’d be happy to do so.

Avatar_pragsmall
26 Mar 2014, 20:46
Joel VanderWerf (2 posts)

Paul,

Yes, now I see the paragraph about tuple spaces in yesterday’s draft. I had no idea this was your background. Just started reading your paper on global synchronization. This makes me even more interested to hear your prognosis for the future of tuple spaces.

Not sure if there’s anything I would suggest adding to that paragraph. You already have the wikipedia link, which is a good starting point. You might mention M. Seki’s book on distributed ruby (also published by PragProg), which has three chapters on the Rinda implementation of Linda. Rinda is very accessible and great for learning, though not suitable for most production uses.

I’d be flattered if you want to add a link to Tupelo, but of course it is only one among many, and it’s not mature. Tupelo stands out in that it takes a radically different architectural approach from Linda, River/JavaSpaces, and, well, any other tuplespace I’ve seen (though there are some similarities to recent distributed transactional databases like VoltDB, Calvin, and Datomic). Briefly, since this is, after all, a forum about 7CM7W: Tupelo’s extreme distribution model decentralizes all storage, searching, wait-lists, and synchronization; transactions provide optimistic concurrency as an alternative to lock tuples; subspaces manage the distribution load. It would be great to continue this discussion (elsewhere, to avoid boring everyone else!), if you’re interested (I’m thinking about the ‘collect’ problem).

Icon_pragsmall
27 Mar 2014, 10:14
Paul Butcher (34 posts)

I’d be very happy to discuss further, Joel - feel free to drop me an e-mail (paul at paulbutcher.com).

  You must be logged in to comment