A Survey of Concurrency Constructs. Ted Leung Sun

Similar documents
Executive Summary. It is important for a Java Programmer to understand the power and limitations of concurrent programming in Java using threads.

The Actor Model. Towards Better Concurrency. By: Dror Bereznitsky

Concurrency. Unleash your processor(s) Václav Pech

Concurrency: what, why, how

Declarative concurrency. March 3, 2014

Problems with Concurrency. February 19, 2014

Dealing with Issues for Interprocess Communication

Understanding Hardware Transactional Memory

Seminar on Languages for Scientific Computing Aachen, 6 Feb Navid Abbaszadeh.

General Overview of Mozart/Oz

Identity, State and Values

Shared state model. April 3, / 29

Concurrency: what, why, how

Tackling Concurrency With STM. Mark Volkmann 10/22/09

Tackling Concurrency With STM

Persistent Data Structures and Managed References

Declarative Concurrency (CTM 4)

Monitors; Software Transactional Memory

CPL 2016, week 10. Clojure functional core. Oleg Batrashev. April 11, Institute of Computer Science, Tartu, Estonia

Stuart

Akka: Simpler Concurrency, Scalability & Fault-tolerance through Actors. Jonas Bonér Viktor Klang

On Academic Dishonesty. Declarative Computation Model. Single assignment store. Single assignment store (2) Single assignment store (3)

Overview. Distributed Computing with Oz/Mozart (VRH 11) Mozart research at a glance. Basic principles. Language design.

CS377P Programming for Performance Multicore Performance Synchronization

Concurrent & Distributed Systems Supervision Exercises

Middleware-Konzepte. Tuple Spaces. Dr. Gero Mühl

Outline. Database Tuning. Ideal Transaction. Concurrency Tuning Goals. Concurrency Tuning. Nikolaus Augsten. Lock Tuning. Unit 8 WS 2013/2014

Monitors; Software Transactional Memory

Synchronization. CSCI 5103 Operating Systems. Semaphore Usage. Bounded-Buffer Problem With Semaphores. Monitors Other Approaches

Declarative Concurrency (CTM 4)

Programming Language Concepts, cs2104 Lecture 01 ( )

Advances in Programming Languages

Database Management and Tuning

Improving the Practicality of Transactional Memory

Lecture 7: Transactional Memory Intro. Topics: introduction to transactional memory, lazy implementation

An Introduction to Parallel Systems

Scala Actors. Scalable Multithreading on the JVM. Philipp Haller. Ph.D. candidate Programming Methods Lab EPFL, Lausanne, Switzerland

Concurrency: Past and Present

Programming Languages and Techniques (CIS120)

Introduction Basics Concurrency Conclusion. Clojure. Marcel Klinzing. December 13, M. Klinzing Clojure 1/18

Ozma: Extending Scala with Oz Concurrency

Clojure Lisp for the Real clojure.com

CSCI-GA Scripting Languages

Programming Safe Agents in Blueprint. Alex Muscar University of Craiova

The New Java Technology Memory Model

The Rise and Rise of Dataflow in the JavaVerse

CMSC 330: Organization of Programming Languages

CONCURRENCY AND THE ACTOR MODEL

Agenda. Designing Transactional Memory Systems. Why not obstruction-free? Why lock-based?

Reminder from last time

Scalable Performance for Scala Message-Passing Concurrency

JVM ByteCode Interpreter

Problems with Concurrency

State, Object-Oriented Programming Explicit State, Polymorphism (CTM ) Objects, Classes, and Inheritance (CTM )

Synchronization. CS61, Lecture 18. Prof. Stephen Chong November 3, 2011

CS Programming Languages: Scala

Reference types in Clojure. April 2, 2014

Clojure Lisp for the Real #clojure

ECE519 Advanced Operating Systems

Lecture 21: Transactional Memory. Topics: consistency model recap, introduction to transactional memory

Threads Tuesday, September 28, :37 AM

Processor speed. Concurrency Structure and Interpretation of Computer Programs. Multiple processors. Processor speed. Mike Phillips <mpp>

Data Structures in Functional Languages

Programming Language Concepts, cs2104 Lecture 09 ( )

9/21/17. Outline. Expression Evaluation and Control Flow. Arithmetic Expressions. Operators. Operators. Notation & Placement

Functional Languages. CSE 307 Principles of Programming Languages Stony Brook University

Concurrent Programming Issues & Readers/Writers

Concurrency control CS 417. Distributed Systems CS 417

CSE Traditional Operating Systems deal with typical system software designed to be:

Multithreading and Interactive Programs

Locks and Threads and Monads OOo My. Stephan Bergmann StarOffice/OpenOffice.org Sun Microsystems

Lecture 21: Transactional Memory. Topics: Hardware TM basics, different implementations

Synchronization SPL/2010 SPL/20 1

Scheduling Transactions in Replicated Distributed Transactional Memory

High-level Parallel Programming: Scala on the JVM

CSE 451: Operating Systems Winter Lecture 7 Synchronization. Steve Gribble. Synchronization. Threads cooperate in multithreaded programs

Introduction to Functional Programming and Haskell. Aden Seaman

Lecture 20: Transactional Memory. Parallel Computer Architecture and Programming CMU , Spring 2013

6 Transactional Memory. Robert Mullins

Linked Lists: Locking, Lock-Free, and Beyond. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit

CMSC Computer Architecture Lecture 12: Multi-Core. Prof. Yanjing Li University of Chicago

Semantic Analysis. Outline. The role of semantic analysis in a compiler. Scope. Types. Where we are. The Compiler Front-End

Simon Peyton Jones (Microsoft Research) Tokyo Haskell Users Group April 2010

Atomic Transac1ons. Atomic Transactions. Q1: What if network fails before deposit? Q2: What if sequence is interrupted by another sequence?

Outline. Database Tuning. What is a Transaction? 1. ACID Properties. Concurrency Tuning. Nikolaus Augsten. Introduction to Transactions

High Performance Computing Course Notes Shared Memory Parallel Programming

Warm-up question (CS 261 review) What is the primary difference between processes and threads from a developer s perspective?

Atomicity via Source-to-Source Translation

Assumptions. History

Concept of a process

COS 326 David Walker. Thanks to Kathleen Fisher and recursively to Simon Peyton Jones for much of the content of these slides.

Chapter Machine instruction level 2. High-level language statement level 3. Unit level 4. Program level

Transactional Memory

Scala, Your Next Programming Language

Chapter 5 Concurrency: Mutual Exclusion. and. Synchronization. Operating Systems: Internals. and. Design Principles

Multi-core Parallelization in Clojure - a Case Study

Conflict Detection and Validation Strategies for Software Transactional Memory

Clojure. A Dynamic Programming Language for the JVM. Rich Hickey

Programming Systems in Artificial Intelligence Functional Programming

Lecture 6 (cont.): Semaphores and Monitors

Transcription:

A Survey of Concurrency Constructs Ted Leung Sun Microsystems ted.leung@sun.com @twleung

16 threads

128 threads

Today s model Threads Program counter Own stack Shared Memory Locks

Some of the problems Locks manually lock and unlock lock ordering is a big problem locks are not compositional How do we decide what is concurrent? Need to pre-design, but now we have to retrofit concurrency via new requirements

Design Goals/Space Mutual Exclusion Serialization / Ordering Inherent / Implicit vs Explicit Fine / Medium / Coarse grained Composability

A good solution Is substantially less error prone Makes it much easier to identify concurrency Runs on today s (and future) parallel hardware Works if you keep adding cores/threads

Theoretical Models Actors CSP CCS petri-nets pi-calculus join-calculus Functional Programming

Theoretical Models Actors CSP CCS petri-nets pi-calculus join-calculus Functional Programming

Implementation matters Threads are not free Message sending is not free Context/thread switching is not free Lock acquire/release is not free

The models Transactional Memory Persistent data structures Actors Dataflow Tuple spaces

Transactional Memory Original paper on STM 1995 Idea goes as far back as 1986 Tom Knight (Hardware Transactional Memory) First appearance in a programming language Concurrent Haskell 2005

The Model Use transactions on items in memory Enclose code in begin/end blocks Variations specify manual abort/retry specify an alternate path (way of controlling manual abort)

Example (defn deposit [account amount] (dosync (let [owner (account :owner) balance-ref (account :balance-ref)] (do (alter balance-ref + amount) (println depositing amount (account :owner)))))))

STM Design Space STM Algorithms / Strategies Granularity word vs block Locks vs Optimistic concurrency Conflict detection eager vs lazy Contention management

STM Problems Non transactional access to STM cells Non abortable operations I/O STM Overhead read/write barrier elimination Where to place transaction boundaries? Still need condition variables ordering problems are important 1/3 of non-deadlock problems in one study

Implementations Haskell/GHC Use logs and aborts txns Clojure STM - via Refs based on ML Refs to confine changes, but ML Refs have no automatic (i.e. STM) concurrency semantics only for Refs to aggregates Implementation uses MVCC Persistent data structures enable MVCC allowing decoupling of readers/writers (readers don t wait)

Persistent Data Structures Original formulation circa 1981 Formalization 1986 Sarnoff Popularized by Clojure

The model Upon update, previous versions are still available preserve functionalness both versions meet O(x) characteristics In Clojure, combined with STM Motivated by copy on write hash-map, vector, sorted map

Available data structures Lists, Vectors, Maps hash list based on VLists VDList - deques based on VLists red-black trees

Available data structures Real Time Queues and Deques deques, output-restricted deques binary random access lists binomial heaps skew binary random access lists skew binomial heaps catenable lists heaps with efficient merging catenable deques

Problems Not really a full model Oriented towards functional programming

Actors Invented by Carl Hewitt at MIT (1973) Formal Model Programming languages Hardware Led to continuations, Scheme Recently revived by Erlang Erlang s model is not derived explicitly from Actors

The Model

Example object account extends Actor { } private var balance = 0 def act() { loop { react { case Withdraw(amount) => balance -= amount sender! Balance(balance) case Deposit(amount) => balance += amount sender! Balance(balance) case BalanceRequest => sender! Balance(balance) case TerminateRequest => } }

Problems with actors DOS of the actor mail queue Multiple actor coordination reinvent transactions? Actors can still deadlock and starve Programmer defines granularity by choosing what is an actor

Actor Implementations Scala Scala Actors Lift Actors Erlang CLR F# / Axum

Java kilim http://www.malhar.net/sriram/kilim/ Actor Foundry http://osl.cs.uiuc.edu/af/ actorom http://code.google.com/p/actorom/ Actors Guild http://actorsguildframework.org/

Measuring performance actor creation? message passing? memory usage?

Erlang vs JVM Erlang per process GC heap tail call distributed JVM per JVM heap no tail call (fixed in JSR-292?) not distributed 2 kinds of actors (Scala)

Actor variants Kamaelia messages are sent to named boxes coordination language connects outboxes to inboxes box size is explicitly controllable

Actor variants Clojure Agents Designed for loosely coupled stuff Code/actions sent to agents Code is queued when it hits the agent Agent framework guarantees serialization State of agent is always available for read (unlike actors which could be busy processing when you send a read message) not in favor of transparent distribution Clojure agents can operate in an open world - actors answer a specific set of messages

Last thoughts on Actors Actors are an assembly language OTP type stuff and beyond Akka - Jonas Boner http://github.com/jboner/akka

Dataflow Bill Ackerman s PhD Thesis at MIT (1984) Declarative Concurrency in functional languages Research in the 1980 s and 90 s Inherent concurrency Turns out to be very difficult to implement Interest in declarative concurrency is slowly returning

The model Dataflow Variables create variable bind value read value or block Threads Dataflow Streams List whose tail is an unbound dataflow variable Deterministic computation!

Example: Variables 1 object Test5 extends Application { import DataFlow._ val x, y, z = new DataFlowVariable[Int] val main = thread { println("thread 'main'") x << 1 println("'x' set to: " + x()) println("waiting for 'y' to be set...") if (x() > y()) { z << x println("'z' set to 'x': " + z()) } else { z << y println("'z' set to 'y': " + z()) } } x.shutdown y.shutdown z.shutdown v.shutdown

Example: Variables 2 object Test5 extends Application { val sety = thread { println("thread 'sety', sleeping...") Thread.sleep(5000) y << 2 println("'y' set to: " + y()) } // shut down the threads main! 'exit sety! 'exit } System.exit(0)

object Test4 extends Application { import DataFlow._ Example: Streams def ints(n: Int, max: Int, stream: DataFlowStream[Int]): Unit = if (n!= max) { println("generating int: " + n) stream <<< n ints(n + 1, max, stream) } def sum(s: Int, in: DataFlowStream[Int], out: DataFlowStream[Int]): Unit = { println("calculating: " + s) out <<< s sum(in() + s, in, out) } def printsum(stream: DataFlowStream[Int]): Unit = { println("result: " + stream()) printsum(stream) } val producer = new DataFlowStream[Int] val consumer = new DataFlowStream[Int] } thread { ints(0, 1000, producer) } thread { sum(0, producer, consumer) } thread { printsum(consumer) }

Example: Streams (Oz) fun {Ints N Max} if N == Max then nil else {Delay 1000} N {Ints N+1 Max} end end fun {Sum S Stream} case Stream of nil then S [] H T then S {Sum H+S T} end end local X Y in thread X = {Ints 0 1000} end thread Y = {Sum 0 X} end {Browse Y} end

Implementations Mozart Oz http://www.mozart-oz.org/ Jonas Boner s Scala library (now part of Akka) http://github.com/jboner/scala-dataflow dataflow variables and streams Ruby library http://github.com/larrytheliquid/dataflow dataflow variables and streams Groovy http://code.google.com/p/gparallelizer/

Variations Futures Originated in Multilisp Eager/speculative evaluation Implementation quality matters I-Structures Id, ph (Parallel Haskell) Single assignment arrays cannot be rebound => no streams

Problems Can t handle non-determinism like a server Need ports this leads to actor like things

Tuple Spaces Originated in Linda (1984) Popularized by Jini

The Model Three operations write() (out) take() (in) read()

The Model Space uncoupling Time uncoupling Readers are decoupled from Writers Content addressable by pattern matching Can emulate Actor like continuations CSP Message Passing Semaphores

Example public class Account implements Entry { public Integer accountno; public Integer value; public Account() {... } public Account(int accountno, int value) { this.accountno = newinteger(accountno); this.value = newinteger(value); } } try { Account newaccount = new Account(accountNo, value); space.write(newaccount, null, Lease.FOREVER); } space.read(accountno);

Implementations Jini/JavaSpaces http://incubator.apache.org/river/river/index.html BlitzSpaces http://www.dancres.org/blitz/blitz_js.html PyLinda http://code.google.com/p/pylinda/ Rinda built in to Ruby

Problems Low level High latency to the space - the space is contention point / hot spot Scalability More for distribution than concurrency

Projects Scala Erlang Clojure Kamaelia Haskell Axum/F# Mozart/Oz Akka

Work to be done More in depth comparisons on 4+ core platforms Higher level frameworks Application architectures/patterns Web Middleware

Final thoughts Shared State is troublesome immutability or no sharing It s too early

References Actors: A Model of Concurrent Computation in Distributed Systems - Gul Agha - MIT Press 1986 Concepts, Techniques, and Models of Computer Programming - Peter Van Roy and Seif Haridi - MIT Press 2004

Q&A Thanks!