• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Designing for Concurrency

Designing for Concurrency



Presenting traditional and less traditional approaches to designing concurrent systems.

Presenting traditional and less traditional approaches to designing concurrent systems.



Total Views
Views on SlideShare
Embed Views



1 Embed 7

http://www.linkedin.com 7



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Designing for Concurrency Designing for Concurrency Presentation Transcript

    • Designing for Concurrency Susan Potter Finsignia August 2010
    • Types of Clients Hedge firms (e.g. Stark, CIG, CS) Investment banks (e.g. BofA) Trading technology (SaaS/ASP) firms
    • Concurrent Applications market data trading systems (front office) risk management (middle office) accounts/party service (back office)
    • Traditional Approaches Task-based thread [pools] (e.g. database connections, server sockets) Hand coded locks (to access shared memory "safely") Data: sharding or replication (to increase throughput on data access)
    • Less Traditional Approaches Actor-based processes (e.g. message passing like in Erlang) Software Transactional Memory (STM) (consistent and safe way to access shared state) Data: decentralized datastores (run map/reduce queries on many nodes at once)
    • Task-based vs Actor-based task threads access shared mailboxes buffer incoming state in objects messages actors do not share state, task threads compete for thus not competing for locks locks on objects messages sent synchronous operations asynchronously within task thread actors react to messages sent limited task scheduling (e. to them g. wait, notify)
    • Actor-based Processes
    • When might actors be better? complexity of the task-based model becomes bottleneck (debugging race conditions, deadlocks, livelocks, starvation). Depends on your use case. system is event-driven conceptually. Easier to translate to high level abstraction in actor-based models.
    • Locks vs STM Flexibility: fine vs coarse Analogous to database grained choice transaction recording Pessimistic locking each txn as log entry Locking semantic need Optimistic reading to be hand coded Atomic transaction Composable operations Supports composable are not well supported operations
    • Software Transactional Memory (STM) Source: Armstrong on Software
    • When to use STM? Using more cores/processors (STM=performance++) on larger numbers of cores/processors (~>=4) Hand coding and debugging locking semantics for application becomes your bottleneck to prevent deadlocks and livelocks Priority inversion often hinders performance BUT YOU CAN'T use STM when operation on shared state cannot be undone. Must be undoable!
    • Replication vs Decentralized Can improve throughput Improve throughput, Some flexibility: replication performance of complex strategies for a few use cases queries using map/reduce Requires full replica(s) of data Flexibility to optimize two of set on each node three: Consistency, Availability, Partition tolerance (CAP Theorem) Does not require full replica(s) of data set
    • When to use decentralized data? Large data set you want distribute without creating/managing your own sharding scheme Want to optimize two of CAP Run distributed map/reduce complex queries BUT datastore should satisfy your other needs first. Usually key-value/bucket lookup, not RDBMS!
    • Other Approaches...(not in production) Compiler parallel optimizations e.g. Haskell sparks Persistent data structures to aid concurrency throughput by better API design
    • General Tips Use SLA metrics/measures to optimize relevant parts of your concurrent system judiciously Ensure your applications fit use case(s) for approach Test your hypothesis by benchmarking NEVER assume your changes have made the impact you expect. There is no silver bullet: think, implement and test!
    • Questions Twitter: @SusanPotter GitHub: http://github.com/mbbx6spp Email: susan@finsignia.com