Showing papers by "Michael Spear published in 2016"

Practical condition synchronization for transactional memory

Abstract: Few transactional memory implementations allow for condition synchronization among transactions. The problems are many, most notably the lack of consensus about a single appropriate linguistic construct, and the lack of mechanisms that are compatible with hardware transactional memory. In this paper, we introduce a broadly useful mechanism for supporting condition synchronization among transactions. Our mechanism supports a number of linguistic constructs for coordinating transactions, and does so without introducing overhead on in-flight hardware transactions. Experiments show that our mechanisms work well, and that the diversity of linguistic constructs allows programmers to chose the technique that is best suited to a particular application.

The Mimir Approach to Transactional Output

Abstract: In order to use transactional memory (TM) in place of locks, it is necessary to design linguistic mechanisms that enable transactions to achieve the same outcomes as lock-based code. The mechanisms need not match their lock-based equivalents exactly, but must provide the same abilities “in spirit,” so that programmers can (perhaps with nontrivial code rewriting) achieve the same behaviors and guarantees from transactions as with locks. In this paper, we focus on the question of transactional output, and introduce the Mimir methodology. Mimir employs an observation about two-phase locking and language-level transactional semantics to enable deferred output operations that appear to execute in isolation with respect to all concurrent transactions, but without serializing those other transactions. The technique employs ephemeral privatization and retry-based condition synchronization in a manner that is invisible to concurrent transactions. Most significantly, Mimir avoids buffering of data in order to defer output, and is compatible with both software and hardware TM.

Languages Must Expose Memory Heterogeneity

Abstract: The last decade has seen an explosion in new and innovative memory technologies. While certain technologies, like transactional memory, have seen adoption at the language level, others, such as sandboxed memory, scratchpad memory, and persistent memory, have not received any systematic programming language support. This is true even though the underlying compiler-level mechanisms for these mechanisms are similar. In this paper, we argue that programming languages must be enhanced to expose heterogeneous memory technologies to programmers, so that they can enjoy the benefits of those technologies and be able to reason about programs that use the advanced features of novel memory technologies. We sketch a language design that allows programmers to specify memory requirements and behaviors, for both data and code. We further describe how a compiler can support such a language and suggest hardware improvements that can improve efficiencies of heterogeneous memories.

Towards migrating computation to distributed memory caches

Abstract: Memcached and other in-memory distributed key-value stores play a critical role in large-scale web applications, by reducing traffic to persistent storage and providing an easy-to-access look-aside cache in which programmers can store arbitrary data. These caches typically have a narrow interface, consisting only of gets, sets, and compare-and-set. In the worst case, this interface can cause significant inefficiencies as clients get large data items, perform small changes, and then set the updated items back into the cache.We extend memcached to allow clients to execute code directly in the cache. An idealized evaluation on micro-benchmarks based on workload traces from a Cable/Internet service provider shows compelling performance, leading to a recommendation that further research be conducted to make in-cache fetch-and-phi safe and programmer-friendly, and that researchers consider whether a truly distributed cloud platform should make it easier for programmers to execute custom code at all levels of the software stack.