Skip to main content

Home/ Coders/ Group items tagged multithreading

Rss Feed Group items tagged

Matteo Spreafico

Joe Duffy's Weblog - OnBeingStateful - 0 views

  • The biggest question left unanswered in my mind is the role state will play in software of the future.
    • The biggest question left unanswered in my mind is the role state will play in software of the future.

      That seems like an absurd statement, or a naïve one at the very least.  State is everywhere:

      • The values held in memory.
      • Data locally on disk.
      • Data in-flight that is being sent over a network.
      • Data stored in the cloud, including on a database, remote filesystem, etc.

      Certainly all of these kinds of state will continue to exist far into the future.  Data is king, and is one major factor that will drive the shift to parallel computing.  The question then is how will concurrent programs interact with this state, read and mutate it, and what isolation and synchronization mechanisms are necessary to do so?

  • Many programs have ample gratuitous dependencies, simply because of the habits we’ve grown accustomed to over 30 odd years of imperative programming.  Our education, mental models, books, best-of-breed algorithms, libraries, and languages all push us in this direction.  We like to scribble intermediary state into shared variables because it’s simple to do so and because it maps to our von Neumann model of how the computer works.
  • ...3 more annotations...
  • We need to get rid of these gratuitous dependencies.  Merely papering over them with a transaction—making them “safe”—doesn’t do anything to improve the natural parallelism that a program contains.  It just ensures it doesn’t crash.  Sure, that’s plenty important, but providing programming models and patterns to eliminate the gratuitous dependencies also achieves the goal of not crashing but with the added benefit of actually improving scalability too.  Transactions have worked so well in enabling automatic parallelism in databases because the basic model itself (without transactions) already implies natural isolation among queries.  Transactions break down and scalability suffers for programs that aren’t architected in this way.  We should learn from the experience of the database community in this regard
  • There will always be hidden mutation of shared state inside lower level system components.  These are often called “benevolent side-effects,” thanks to Hoare, and apply to things like lazy initialization and memorization caches.  These will be done by concurrency ninjas who understand locks.  And their effects will be isolated by convention.
  • Even with all of this support, we’d be left with an ecosystem of libraries like the .NET Framework itself which have been built atop a fundamentally mutable and imperative system.  The path forward here is less clear to me, although having the ability to retain a mutable model within pockets of guaranteed isolation certainly makes me think the libraries are salvageable.  Thankfully, the shift will likely be very gradual, and the pieces that pose substantial problems can be rewritten in place incrementally over time.  But we need the fundamental language and type system support first.
Joel Bennett

Parallel Performance: Optimize Managed Code For Multi-Core Machines -- MSDN Magazine, O... - 0 views

    An introduction to the Microsoft Task Parallel Library (for .Net).  The Parallel FX Library is currently (Dec, 2007) in CTP.
Joel Bennett

Concurrency: What Every Dev Must Know About Multithreaded Apps -- MSDN Magazine, August... - 0 views

    A comprehensive guide to the basics of multithreaded development...
Joel Bennett

Software Transactional Memory (MSDN Blog: Developing for Developers) - 0 views

    A great article explaining Software Transactional Memory for programmers who've never heard of it.
1 - 6 of 6
Showing 20 items per page