ABSTRACT
Creating components based on concurrent and parallel algorithms and data structures often requires more attention to "engineering" issues not seen with most other libraries. Components created in the "obvious" way sometimes turn out to be wrong, to perform poorly, or are unusable in most applications, because the abstractions in which they are expressed are leaky, imprecise, or incorrectly specified. While many of these issues are encountered in other aspects of concurrent programming, the impact is accentuated when they continue to leak through to APIs provided by library components. This presentation surveys some examples and lessons learned from the design, implementation, and applications of the java.util.concurrent library, including those surrounding memory models, resource management and garbage collection, thread management, optimization, and code generation.
Index Terms
Abstraction failures in concurrent programming
Recommendations
Certified concurrent abstraction layers
PLDI '18Concurrent abstraction layers are ubiquitous in modern computer systems because of the pervasiveness of multithreaded programming and multicore hardware. Abstraction layers are used to hide the implementation details (e.g., fine-grained synchronization) ...
Transactions for concurrent object-oriented programming systems
Proceedings of the ACM SIGPLAN Workshop on Object-Based Concurrent ProgrammingConcurrent object-oriented programming systems (COOPS) require support for fault tolerance, concurrency control, consistent commitment of changes and program-initiated rollback. It is sometimes suggested that the classical transaction processing model ...
Transactions for concurrent object-oriented programming systems
OOPSLA/ECOOP '88: Proceedings of the 1988 ACM SIGPLAN workshop on Object-based concurrent programmingConcurrent object-oriented programming systems (COOPS) require support for fault tolerance, concurrency control, consistent commitment of changes and program-initiated rollback. It is sometimes suggested that the classical transaction processing model ...
Comments