Group items tagged caching - Coders

fausse ray ban clubmaster soldes Ils menacent - 0 views

started by subsequent1 subsequent1 on 09 Jun 14 no follow-up yet

1More

Setting up extension development environment - MDC - 0 views

shared by Rick Fan on 11 Oct 08 - No Cached

Cache Visualizer - VS2005 - 0 views

blog.bretts.net/2e-45c6-b24e-3a286fce1b66.aspx @public addins develop tools visualizers vs

shared by Joel Bennett on 09 Feb 07 - Cached

6More

Joe Duffy's Weblog - OnBeingStateful - 0 views

www.bluebytesoftware.com/...OnBeingStateful.aspx threading Functionallanguages F# STM MultiThreading Frontiers

shared by Matteo Spreafico on 10 Aug 09 - Cached

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

Cancel
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?
...

Cancel
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.
...

Cancel
...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
...

Cancel
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.
...

Cancel
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.
...

Cancel