<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Tuple spaces implementations and their efficiency · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/1612.02979/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/1612.02979/feed.xml" rel="self" type="application/rss+xml" /><item><title>Tuple spaces implementations and their efficiency — mentioned by imglorp</title><link>https://news.ycombinator.com/item?id=35747852</link><guid isPermaLink="false">urn:hackerpapers:mention:1612.02979:35747852</guid><pubDate>Fri, 28 Apr 2023 22:22:33 GMT</pubDate><description>&lt;p&gt;Tuple spaces implementations and their efficiency - 2016 https://arxiv.org/pdf/1612.02979.pdf &amp;gt; SUMMARY &amp;gt; Among the paradigms for parallel and distributed computing, the one popularized with Linda, and based on tuple spaces, is one of the least used, despite the fact of being intuitive, easy to understand and to use. A tuple space is a repository, where processes can add, withdraw or read tuples by means of atomic operations. Tuples may contain different values, and processes can inspect their content via pattern matching. The lack of a reference implementation for this paradigm has prevented…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/1612.02979/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.DC</category></item><item><title>Tuple spaces implementations and their efficiency — mentioned by makmanalp</title><link>https://news.ycombinator.com/item?id=17636687</link><guid isPermaLink="false">urn:hackerpapers:mention:1612.02979:17636687</guid><pubDate>Sun, 29 Jul 2018 05:36:06 GMT</pubDate><description>&lt;p&gt;It&amp;#x27;s better to think of tuple spaces as a concurrency / communications model than an implementation. So it&amp;#x27;s more like &amp;quot;the actor model&amp;quot; rather than Erlang&amp;#x27;s or Java/Akka&amp;#x27;s specific implementation of it. It&amp;#x27;s more about &amp;quot;if we had this type of system with these constraints and these features, abstracting away these details, what would we gain or lose?&amp;quot;. You&amp;#x27;re right that in the end a good or bad implementation can make or break things (take a look at this paper: https://arxiv.org/abs/1612.02979), but that&amp;#x27;s not the point, at least with the original paper. The interesting thoughts from the…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/1612.02979/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.DC</category></item></channel></rss>
