Conference Paper

Dynamic Message Processing and Transactional Memory in the Actor Model

Authors:
To read the full-text of this research, you can request a copy directly from the authors.

Abstract

With the trend of ever growing data centers and scaling core counts, simple programming models for efficient distributed and concurrent programming are required. One of the successful principles for scalable computing is the actor model, which is based on message passing. Actors are objects that hold local state that can only be modified by the exchange of messages. To avoid typical concurrency hazards, each actor processes messages sequentially. However, this limits the scalability of the model. We have shown in former work that concurrent message processing can be implemented with the help of transactional memory, ensuring sequential processing, when required. This approach is advantageous in low contention phases, however, does not scale for high contention phases. In this paper we introduce a combination of dynamic resource allocation and non-transactional message processing to overcome this limitation. This allows for efficient resource utilization as these two mechanisms can be handled in parallel. We show that we can substantially reduce the execution time of high-contention workloads in a micro-benchmark as well as in a real-world application.

No full-text available

Request Full-text Paper PDF

To read the full-text of this research,
you can request a copy directly from the authors.

... Actor programming models provide desirable primitives for concurrent and distributed programming [2,4,27], which of late have evoked a strong interest in the database community [9]. To holistically meet the challenging requirements imposed on OLTP systems, we propose a new actor programming model in relational databases called Relational Actors (or reactors for short). ...
... In contrast to regular actors, reactors comprise an explicit memory model with transactions and relational querying, substantially simplifying program logic. These features make the reactor model differ significantly from the virtual actors of Orleans [7] and from other actor-based frameworks [4,27]. Recent work in Orleans has focused on a vision of integrating traditional data-management functionality in a virtual actor runtime for the middle tier of a classic three-tier architecture [9,23]. ...
Preprint
The requirements for OLTP database systems are becoming ever more demanding. Domains such as finance and computer games increasingly mandate that developers be able to encode complex application logic and control transaction latencies in in-memory databases. At the same time, infrastructure engineers in these domains need to experiment with and deploy OLTP database architectures that ensure application scalability and maximize resource utilization in modern machines. In this paper, we propose a relational actor programming model for in-memory databases as a novel, holistic approach towards fulfilling these challenging requirements. Conceptually, relational actors, or reactors for short, are application-defined, isolated logical actors that encapsulate relations and process function calls asynchronously. Reactors ease reasoning about correctness by guaranteeing serializability of application-level function calls. In contrast to classic transactional models, however, reactors allow developers to take advantage of intra-transaction parallelism and state encapsulation in their applications to reduce latency and improve locality. Moreover, reactors enable a new degree of flexibility in database deployment. We present ReactDB, a system design exposing reactors that allows for flexible virtualization of database architecture between the extremes of shared-nothing and shared-everything without changes to application code. Our experiments illustrate latency control, low overhead, and asynchronicity trade-offs with ReactDB in OLTP benchmarks.
... The first one tries to improve the performance of all mechanisms used to execute Actors efficiently, mainly the Actor scheduling strategies [6,20,34,35]. The second approach, instead, follows the direction of extending the AM with new features and constructs [10,19,22,25,27,33]. Our work falls in the second category. ...
... Some authors proposed to use transactional memory to manage concurrent modifications of the Actor state [22], rather than an ad-hoc internal scheduler [33]. Incoming messages are executed in parallel on a thread pool, and the state modifications are managed as transactions, thus if two modifications conflict, the state is reverted and the modification executed again in a different order. ...
Article
Full-text available
The Actor-based programming model is largely used in the context of distributed systems for its message-passing semantics and neat separation between the concurrency model and the underlying hardware platform. However, in the context of a single multi-core node where the performance metric is the primary optimization objective, the “pure” Actor Model is generally not used because Actors cannot exploit the physical shared-memory, thus reducing the optimization options. In this work, we propose to enrich the Actor Model with some well-known Parallel Patterns to face the performance issues of using the “pure” Actor Model on a single multi-core platform. In the experimental study, conducted on two different multi-core systems by using the C++ Actor Framework, we considered a subset of the Parsec benchmarks and two Savina benchmarks. The analysis of results demonstrates that the Actor Model enriched with suitable Parallel Patterns implementations provides a robust abstraction layer capable of delivering performance results comparable with those of thread-based libraries (i.e. Pthreads and FastFlow) while offering a safer and versatile programming environment.
... The first one aims to improve the performance of all mechanisms used to execute Actors efficiently, mainly the scheduling strategies [7], [31], [20], [32]. The second approach, instead, follows the direction of extending the Actor model with new features and constructs [30], [22], [11], [25]. ...
... In [22] the authors proposed to use transactional memory to manage concurrent modifications of the Actor state, rather than an ad-hoc internal scheduler as in [30]. Incoming messages are executed in parallel on a thread pool and the state modifications are managed as transitions, thus if two modification conflicts the state is reverted and the modification executed again in different order. ...
Conference Paper
Full-text available
The Actor-based parallel programming model is having its momentum in the context of IoT and Cloud computing thanks to a clear separation between the concurrency model and the underlying HW platform. The message-driven style of non-blocking and asynchronous interactions via immutable messages among Actors fits well with the complexity of modern heterogeneous distributed platforms. However, in the context of High-Performance Computing (HPC) on multi-cores, the Actor model is only marginally used even if we are witnessing the increasing offer of system level language implementations of the model targeting high-throughput and low message latency. In this work, we investigate the advantages and pitfalls of using the Actor model for HPC applications on multi-cores. We considered a notable subset of the Parsec benchmarks and the "C++ Actor Framework" (CAF) as a reference implementation of Actors. The analysis and the experimental results performed on two different multi-core platforms demonstrate that the Actor model enriched with suitable parallel patterns provides a robust abstraction layer capable of supplying performance results comparable with the ones of specialized libraries while offering a more versatile programming environment.
... Actor programming models provide desirable primitives for concurrent and distributed programming [2,4,17]. To provide performance predictability, we propose a new actor programming model in relational databases called Relational Actors (or reactors for short). ...
... In contrast to regular actors, reactors comprise an explicit memory model with transactions and relational querying, substantially simplifying program logic. These features make the reactor model differ significantly from the virtual actors of Orleans [5] and from other actor-based frameworks [4,17]. As explained in Section 2.2, reactors are related to the early work on Argus [23]; however, other than offering relational state representation, the semantics of sub-transactions in reactors differ, and our model provides a logical abstraction for performance predictability that can be virtualized in multiple database configurations in REACTDB. ...
Conference Paper
Full-text available
The requirements for OLTP database systems are becoming ever more demanding. Domains such as finance and computer games increasingly mandate that developers be able to encode complex application logic and control transaction latencies in in-memory databases. At the same time, infrastructure engineers in these domains need to experiment with and deploy OLTP database architectures that ensure application scalability and maximize resource utilization in modern machines. In this paper, we propose a relational actor programming model for in-memory databases as a novel, holistic approach towards fulfilling these challenging requirements. Conceptually, relational actors, or reactors for short, are application-defined, isolated logical actors that encapsulate relations and process function calls asynchronously. Reactors ease reasoning about correctness by guaranteeing serializability of application-level function calls. In contrast to classic transactional models, however, reactors allow developers to take advantage of intra-transaction parallelism and state encapsulation in their applications to reduce latency and improve locality. Moreover, reactors enable a new degree of flexibility in database deployment. We present ReactDB, a system design exposing reactors that allows for flexible virtualization of database architecture between the extremes of shared-nothing and shared-everything without changes to application code. Our experiments illustrate latency control, low overhead, and asynchronicity trade-offs with ReactDB in OLTP benchmarks.
Article
Full-text available
Integrating the actor model into mainstream software platforms is challenging because typical runtime environments, such as the Java Virtual Machine, have been designed for very different concurrency models. Moreover, to enable integration with existing infrastructures, execution modes and constructs foreign to the pure actor model have to be supported. This paper provides an overview of past and current efforts to address these challenges in the context of the Scala programming language.
Article
Full-text available
In this paper we investigate the issue of automatically identifying the "natural" degree of parallelism of an application using software transactional memory (STM), i.e., the workload-specific multiprogramming level that maximizes application's performance. We discuss the importance of adapting the concurrency level to the workload in two different scenarios, a shared-memory and a distributed STM infrastructure. We propose and evaluate two alternative self-tuning methodologies, explicitly tailored for the considered scenarios. In shared-memory STM, we show that lightweight, black-box approaches relying solely on on-line exploration can be extremely effective. For distributed STMs, we introduce a novel hybrid approach that combines model-driven performance forecasting techniques and on-line exploration in order to take the best of the two techniques, namely enhancing robustness despite model's inaccuracies, and maximizing convergence speed towards optimum solutions.
Article
Full-text available
Multiple-point geostatistics is a general statistical framework to model spatial fields displaying a wide range of complex structures. In particular, it allows controlling connectivity patterns that have a critical importance for groundwater flow and transport problems. This approach involves considering data events (spatial arrangements of values) derived from a training image (TI). All data events found in the TI are usually stored in a database, which is used to retrieve conditional probabilities for the simulation. Instead, we propose to sample directly the training image for a given data event, making the database unnecessary. Our method is statistically equivalent to previous implementations, but in addition it allows extending the application of multiple-point geostatistics to continuous variables and to multivariate problems. The method can be used for the simulation of geological heterogeneity, accounting or not for indirect observations such as geophysics. We show its applicability in the presence of complex features, nonlinear relationships between variables, and with various cases of nonstationarity. Computationally, it is fast, easy to parallelize, parsimonious in memory needs, and straightforward to implement.
Article
Full-text available
We introduce CCSTM, a library-based software transactional mem-ory (STM) for Scala, and give an overview of its design and imple-mentation. Our design philosophy is that CCSTM should be a use-ful tool for the parallel programmer, rather than a parallelization mechanism for arbitrary sequential code, or the sole synchroniza-tion primitive in a system. CCSTM expresses transactional reads and writes as explicit method calls on instances of a reference type. Scala's flexible method names, implicit parameters, and closures keep the syntax concise, and the reference instances provide a natural way to ex-press additional STM functionality. We use a novel hybrid of static and dynamic transaction scoping to retain composability while avoiding the barrier overheads that would otherwise result from an implementation as an unprivileged library. Experiments show that CCSTM's performance and scalability are on par with bytecode rewriting STMs.
Conference Paper
Full-text available
We propose a new form of software transactional memory (STM) designed to support dynamic-sized data structures, and we describe a novel non-blocking implementation. The non-blocking property we consider is obstruction-freedom. Obstruction-freedom is weaker than lock-freedom; as a result, it admits substantially simpler and more efficient implementations. A novel feature of our obstruction-free STM implementation is its use of modular contention managers to ensure progress in practice. We illustrate the utility of our dynamic STM with a straightforward implementation of an obstruction-free red-black tree, thereby demonstrating a sophisticated non-blocking dynamic data structure that would be difficult to implement by other means. We also present the results of simple preliminary performance experiments that demonstrate that an "early release" feature of our STM is useful for reducing contention, and that our STM lends itself to the effective use of modular contention managers.
Conference Paper
Full-text available
The problem of programming scalable multicore processors has renewed interest in message-passing languages and frame- works. Such languages and frameworks are typically actor- oriented, implementing some variant of the standard Actor semantics. This paper analyzes some of the more signiflcant efiorts to build actor-oriented frameworks for the JVM plat- form. It compares the frameworks in terms of their execution semantics, the communication and synchronization abstrac- tions provided, and the representations used in the imple- mentations. It analyzes the performance of actor-oriented frameworks to determine the costs of supporting difierent actor properties on JVM. The analysis suggests that with suitable optimizations, standard Actor semantics and some useful communication and synchronization abstractions may be supported with reasonable e-ciency on the JVM plat- form.
Conference Paper
Full-text available
Additive AND/OR graphs are defined as AND/ OR graphs without circuits, which can be considered as folded AND/OR trees; i. e. the cost of a common subproblem is added to the cost as many times as the subproblem occurs, but it is computed only once. Additive ...
Article
Full-text available
We present an actor language which is an extension of a simple functional language, and provide a precise operational semantics for this extension. Actor configurations are open distributed systems, meaning we explicitly take into account the interface with external components in the specification of an actor system. We define and study various notions of equivalence on actor expressions and configurations. Draft 28 July 1 1. Introduction The modern computing environment is becoming increasingly distributed. The semantics of components of open distributed systems is in its infancy. The main features of an open distributed system are that new components can be added, existing components can be replaced, and interconnections can be changed, largely without disturbing the functioning of the system. Components have no control over the components with which they might be connected. The behavior of a component is locally determined by its initial state and the history of its interactions...
Article
Full-text available
Transactional memory (TM) is an appealing abstraction for programming multi-core systems. Potential target applications for TM, such as business software and video games, are likely to involve complex data structures and large transactions, requiring specific software solutions (STM). So far, however, STMs have been mainly evaluated and optimized for smaller scale benchmarks. We revisit the main STM design choices from the perspective of complex workloads and propose a new STM, which we call SwissTM. In short, SwissTM is lock- and word-based and uses (1) optimistic (commit-time) conflict detection for read/write conflicts and pessimistic (encounter-time) conflict detection for write/write conflicts, as well as (2) a new two-phase contention manager that ensures the progress of long transactions while inducing no overhead on short ones. SwissTM outperforms state-of-the-art STM implementations, namely RSTM, TL2, and TinySTM, in our experiments on STMBench7, STAMP, Lee-TM and red-black tree benchmarks. Beyond SwissTM, we present the most complete evaluation to date of the individual impact of various STM design choices on the ability to support the mixed workloads of large applications.
Chapter
An extended concept of indicator kriging allows the production of images that honor any number of multiple-point indicator covariances representing multiple-event experimental frequencies. The technique is applied to the stochastic imaging of phenomena sparsely sampled with complex features that cannot be captured by two-point statistics. -from Authors
Conference Paper
This paper introduces a unified concurrent programming model combining the previously developed Actor Model (AM) and the task-parallel Async-Finish Model (AFM). With the advent of multi-core computers, there is a renewed interest in programming models that can support a wide range of parallel programming patterns. The proposed unified model shows how the divide-and-conquer approach of the AFM and the no-shared mutable state and event-driven philosophy of the AM can be combined to solve certain classes of problems more efficiently and productively than either of the aforementioned models individually. The unified model adds actor creation and coordination to the AFM, while also enabling parallelization within actors. This paper describes two implementations of the unified model as extensions of Habanero-Java and Habanero-Scala. The unified model adds to the foundations of parallel programs, and to the tools available for the programmer to aid in productivity and performance while developing parallel software.
Conference Paper
The actor model has been successfully used for scalable computing in distributed systems. Actors are objects with a local state, which can only be modified by the exchange of messages. One of the fundamental principles of actor models is to guarantee sequential message processing, which avoids typical concurrency hazards, but limits the achievable message throughput. Preserving the sequential semantics of the actor model is, however, necessary for program correctness. In this paper, we propose to add support for speculative concurrent execution in actors using transactional memory (TM). Our approach is designed to operate with message passing and shared memory, and can thus take advantage of parallelism available on distributed and multi-core systems. The processing of each message is wrapped in a transaction executed atomically and in isolation, but concurrently with other messages. This allows us (1) to scale while keeping the dependability guarantees ensured by sequential message processing, and (2) to further increase robustness of the actor model against threats due to the rollback ability that comes for free with transactional processing of messages. We validate our design within the Scala programming language and the Akka framework. We show that the overhead of using transactions is hidden by the improved message processing throughput, thus leading to an overall performance gain.
Article
Transactional memory is an alternative to locks for handling concurrency in multi-threaded environments. Instead of providing critical regions that only one thread can enter at a time, transactional memory records sufficient information to detect and correct for conflicts if they occur. This paper surveys the range of options for implementing software transactional memory in Scala. Where possible, we provide references to implementations that instantiate each technique. As part of this survey, we document for the first time several techniques developed in the implementation of Manchester University Transactions for Scala. We order the implementation techniques on a scale moving from the least to the most invasive in terms of modifications to the compilation and runtime environment. This shows that, while the less invasive options are easier to implement and more common, they are more verbose and invasive in the codes using them, often requiring changes to the syntax and program structure throughout the code.
Conference Paper
Thrashing in transaction processing systems can be prevented by controlling the number of concurrently running transactions. Because the optimal concurrency level strongly depends on the workload characteristics which may change in time, two algorithms for adaptive adjustment of an upper bound for the concurrency level are proposed and compared by simulation.
Book
The advent of multicore processors has renewed interest in the idea of incorporating transactions into the programming model used to write parallel programs. This approach, known as transactional memory, offers an alternative, and hopefully better, way to coordinate concurrent threads. The ACI (atomicity, consistency, isolation) properties of transactions provide a foundation to ensure that concurrent reads and writes of shared data do not produce inconsistent or incorrect results. At a higher level, a computation wrapped in a transaction executes atomically-either it completes successfully and commits its result in its entirety or it aborts. In addition, isolation ensures the transaction produces the same result as if no other transactions were executing concurrently. Although transactions are not a parallel programming panacea, they shift much of the burden of synchronizing and coordinating parallel computations from a programmer to a compiler, to a language runtime system, or to hardware. The challenge for the system implementers is to build an efficient transactional memory infrastructure. This book presents an overview of the state of the art in the design and implementation of transactional memory systems, as of early spring 2010.
Book
The advent of multicore processors has renewed interest in the idea of incorporating transactions into the programming model used to write parallel programs. This approach, known as transactional memory, offers an alternative, and hopefully better, way to coordinate concurrent threads. The ACI (atomicity, consistency, isolation) properties of transactions provide a foundation to ensure that concurrent reads and writes of shared data do not produce inconsistent or incorrect results. At a higher level, a computation wrapped in a transaction executes atomically - either it completes successfully and commits its result in its entirety or it aborts. In addition, isolation ensures the transaction produces the same result as if no other transactions were executing concurrently. Although transactions are not a parallel programming panacea, they shift much of the burden of synchronizing and coordinating parallel computations from a programmer to a compiler, runtime system, and hardware. The challenge for the system implementers is to build an efficient transactional memory infrastructure. This book presents an overview of the state of the art in the design and implementation of transactional memory systems, as of early summer 2006.
Parallel actor monitors
  • C Scholliers
  • E Tanter
  • W D Meuter
Supporting nested transactional memory in logtm
  • M J Moravan
  • J Bobba
  • K E Moore
  • L Yen
  • M D Hill
  • B Liblit
  • M M Swift
  • D A Wood
  • M.J. Moravan