Aspect-oriented programming (AOP) is a technique for improving separation of concerns in software design and implementation. AOP works by providing explicit mechanisms for capturing the structure of crosscutting concerns. This tutorial shows how to use AOP to implement crosscutting conerns in a concise modular way. It works with AspectJ, a seamless aspect-oriented extension to the Java(tm) programming language, and with AspectC, an aspect-oriented extension to C in the style of AspectJ. It also includes a description of their underlying model, in terms of which a wide range of AOP languages can be understood.

Aspect-oriented programming

Aspect] is a simple and practical aspect-oriented extension to Java With just a few new constructs, AspectJ provides support for modular implementation of a range of crosscutting concerns. In AspectJ's dynamic join point model, join points are well-defined points in the execution of the program; pointcuts are collections of join points; advice are special method-like constructs that can be attached to pointcuts; and aspects are modular units of crosscutting implementation, comprising pointcuts, advice, and ordinary Java member declarations. AspectJ code is compiled into standard Java bytecode. Simple extensions to existing Java development environments make it possible to browse the crosscutting structure of aspects in the same kind of way as one browses the inheritance structure of classes. Several examples show that AspectJ is powerful, and that programs written using it are easy to understand.

An overview of AspectJ

AspectJ? is a simple and practical aspect-oriented extension to Java?. With just a few new constructs, AspectJ provides support for modular implementation of a range of crosscutting concerns. In AspectJ's dynamic join point model, join points are well-defined points in the execution of the program; pointcuts are collections of join points; advice are special method-like constructs that can be attached to pointcuts; and aspects are modular units of crosscutting implementation, comprising pointcuts, advice, and ordinary Java member declarations. AspectJ code is compiled into standard Java bytecode. Simple extensions to existing Java development environments make it possible to browse the crosscutting structure of aspects in the same kind of way as one browses the inheritance structure of classes. Several examples show that AspectJ is powerful, and that programs written using it are easy to understand.

/pdf/an-overview-of-aspectj-159di7yz43.pdf

An Overview of AspectJ

Transactional Memory (TM) is emerging as a promising technology to simplify parallel programming. While several TM systems have been proposed in the research literature, we are still missing the tools and workloads necessary to analyze and compare the proposals. Most TM systems have been evaluated using microbenchmarks, which may not be representative of any real-world behavior, or individual applications, which do not stress a wide range of execution scenarios. We introduce the Stanford Transactional Application for Multi-Processing (STAMP), a comprehensive benchmark suite for evaluating TM systems. STAMP includes eight applications and thirty variants of input parameters and data sets in order to represent several application domains and cover a wide range of transactional execution cases (frequent or rare use of transactions, large or small transactions, high or low contention, etc.). Moreover, STAMP is portable across many types of TM systems, including hardware, software, and hybrid systems. In this paper, we provide descriptions and a detailed characterization of the applications in STAMP. We also use the suite to evaluate six different TM systems, identify their shortcomings, and motivate further research on their performance characteristics.

/pdf/stamp-stanford-transactional-applications-for-multi-5ascbp3x5h.pdf

STAMP: Stanford Transactional Applications for Multi-Processing

In this paper we consider productivity challenges for parallel programmers and explore ways that parallel language design might help improve end-user productivity. We offer a candidate list of desirable qualities for a parallel programming language, and describe how these qualities are addressed in the design of the Chapel language. In doing so, we provide an overview of Chapel's features and how they help address parallel productivity. We also survey current techniques for parallel programming and describe ways in which we consider them to fall short of our idealized productive programming model.

/pdf/parallel-programmability-and-the-chapel-language-3fa3iypnkj.pdf

Parallel Programmability and the Chapel Language

Methods and systems for executing nested concurrent threads of a transaction are presented. In one embodiment, in response to executing a parent transaction, a first group of one or more concurrent threads including a first thread is created. The first thread is associated with a transactional descriptor comprising a pointer to the parent transaction.

Methods and systems for transactional nested parallelism

A method and apparatus for providing optimized strong atomicity operations for non-transactional writes is herein described. Locks are acquired upon initial non-transactional writes to memory locations. The locks are maintained until an event is detected resulting in the release of the locks. As a result, in the intermediary period between acquiring and releasing the locks, any subsequent writes to memory locations that are locked are accelerated through non-execution of lock acquire operations.

Efficient non-transactional write barriers for strong atomicity

A method and apparatus for dynamic optimization of strong atomicity barriers is herein described During runtime compilation, code including non-transactional memory accesses that are to conflict with transactional memory accesses is patched to insert transactional barriers at the conflicting non-transactional memory accesses to ensure isolation and strong atomicity However, barriers are omitted or removed from non-transactional memory accesses that do not conflict with transactional memory accesses to reduce barrier execution overhead

Dynamic optimization for removal of strong atomicity barriers

A method and apparatus for optimizing quiescence in a transactional memory system is herein described. Non-ordering transactions, such as read-only transactions, transactions that do not access non-transactional data, and write-buffering hardware transactions, are identified. Quiescence in weak atomicity software transactional memory (STM) systems is optimized through selective application of quiescence. As a result, transactions may be decoupled from dependency on quiescing/waiting on previous non-ordering transaction to increase parallelization and reduce inefficiency based on serialization of transactions.

Optimizing quiescence in a software transactional memory (stm) system

A method and apparatus for providing efficient strong atomicity is herein described. Optimized strong operations may be inserted at non-transactional read accesses to provide efficient strong atomicity. A global transaction value is copied at a beginning of a non-transational function to a local transaction value; essentially creating a local timestamp of the global transaction value. At a non-transactional memory access within the function, a counter value or version value is compared to the LTV to see if a transaction has started updating memory locations, or specifically the memory location accessed. If memory locations have not been updated by a transaction, execution is accelerated by avoiding a full set of slowpath strong atomic operations to ensure validity of data accessed. In contrast, the slowpath operations may be executed to resolve contention between a transactional and non-transaction access contending for the same memory location.

Tatiana Shpeisman

Papers

Methods and systems for transactional nested parallelism

Efficient non-transactional write barriers for strong atomicity

Dynamic optimization for removal of strong atomicity barriers

Optimizing quiescence in a software transactional memory (stm) system

Mechanisms for strong atomicity in a transactional memory system