Sutter's Mill: Concurrency

Concurrency Interview with DevX

Sat, 29 Mar 2008 01:48:38 GMT

I recently spent an hour on the phone to talk concurrency with DevX's Alexa Weber Morales. Part 1 of that interview just went live on the web, and focuses mostly on what concurrency and parallelism are, how to take advantage of multicore chips, and whether concurrency will ever be really accessible to mainstream developers. The site seems to be having intermittent problems displaying the pages; just hit the link a few more times if it doesn't work right away.

Disclaimer: I am not responsible for the article title (yikes! "whisperer"?! my goodness gracious!) and the intro blurb vastly overstates my role (Alexa is being way too kind). But it is true that it's important for us-the-industry to bring concurrency to the mainstream in a grokkable way, as we have already successfully done with OO and GUIs in the past.

New Course Available: Effective Concurrency

Thu, 13 Mar 2008 00:22:27 GMT

Many of you have kindly sent mail about my Effective Concurrency columns and asking when there'll be a course. Well, I'm happy to announce that the answer is: May 19-21, 2008.

Here's the brief information (more details below):

3-Day Seminar: Effective Concurrency

May 19-21, 2008
Bellevue, WA, USA
Developed and taught by Herb Sutter

This course covers the fundamental tools that software developers need to write effective concurrent software for both single-core and multi-core/many-core machines. To use concurrency effectively, we must identify and solve four key challenges:

Leverage the ability to perform and manage work asynchronously
Build applications that naturally run faster on new hardware having more and more cores
Manage shared objects in memory effectively to avoid races and deadlocks
Engineer specifically for high performance

This seminar will equip attendees to reason correctly about concurrency requirements and tradeoffs, to migrate existing code bases to be concurrency-enabled, and to achieve key success factors for a concurrent programming project. Most code examples in the course can be directly translated to popular platforms and concurrency libraries, including Linux, Windows, Java, .NET, pthreads, and the forthcoming ISO C++0x standard.

Note on class size limit and possible waitlist: There is a hard limit on attendance at this first one (really). But if the registration site says you'll get waitlisted, don't give up: Go ahead and sign up anyway because we may be able to put together a second installment of the seminar a week or two later if there's enough interest.

Finally, here's a summary of what we'll cover during the three days.

Fundamentals

Define basic concurrency goals and requirements
Understand applications' scalability needs
Key concurrency patterns

Isolation: Keep Work Separate

Running tasks in isolation and communicate via async messages
Integrating multiple messaging systems, including GUIs and sockets
Building responsive applications using background workers
Threads vs. thread pools

Scalability: Re-enable the Free Lunch

When and how to use more cores
Exploiting parallelism in algorithms
Exploiting parallelism in data structures
Breaking the scalability barrier

Consistency: Don’t Corrupt Shared State

The many pitfalls of locks--deadlock, convoys, etc.
Locking best practices
Reducing the need for locking shared data
Safe lock-free coding patterns
Avoiding the pitfalls of general lock-free coding
Races and race-related effects

Migrating Existing Code Bases to Use Concurrency
Near-Future Tools and Features
High Performance Concurrency

Machine architecture and concurrency
Costs of fundamental operations, including locks, context switches, and system calls
Memory and cache effects
Data structures that support and undermine concurrency
Enabling linear and superlinear scaling

I hope to get to meet some of you here in the Seattle area!

Effective Concurrency: Super Linearity and the Bigger Machine

Wed, 12 Mar 2008 23:37:25 GMT

The latest Effective Concurrency column, "Super Linearity and the Bigger Machine", just went live on DDJ's site, and will also appear in the print magazine. From the article:

There are two main ways to achieve superlinear scalability, or to use P processors to compute an answer more than P times faster...:

Do disproportionately less work.
Harness disproportionately more resources.

Last month, we focused on the first point by illustrating parallel search and how it naturally achieves superlinear speedups when matches are not distributed evenly because some workers get "rich" subranges and will find a match faster, which benefits the whole search because we can stop as soon as any worker finds a match.
This month, we'll conclude examining the first point with a few more examples, and then consider how to achieve superlinear speedups by harnessing more resources—quite literally, running on a bigger machine without any change in the hardware. ...

I hope you enjoy it.

Finally, here are links to previous Effective Concurrency columns (based on the dates they hit the web, not the magazine print issue dates):

July 2007	The Pillars of Concurrency
August 2007	How Much Scalability Do You Have or Need?
September 2007	Use Critical Sections (Preferably Locks) to Eliminate Races
October 2007	Apply Critical Sections Consistently
November 2007	Avoid Calling Unknown Code While Inside a Critical Section
December 2007	Use Lock Hierarchies to Avoid Deadlock
January 2008	Break Amdahl's Law!
February 2008	Going Superlinear
March 2008	Super Linearity and the Bigger Machine

How parallelism demos are useful

Sat, 02 Feb 2008 03:31:16 GMT

In "Break Amdahl's Law!", I described ways to enable scalable applications, and wrote in part:

But don't show me ray-traced bouncing balls or Mandelbrot graphics or the other usual embarrassingly parallel but niche (or downright useless) clichés—what we're looking for are real ideas of real software we could imagine real kids and grandmothers using that could become possible on manycore machines. Here's a quick potential example: Researchers know how to do speech recognition with near-human-quality accuracy in the lab, which is astonishingly good and would enable breakthrough user interfaces if it could be done that reliably in real time. The only trouble is that the software takes a week to run...on a single core. Can it be parallelized, and if so how many cores would we need to get a useful answer in a useful time? Bunches of smart people (and the smart money behind them) are investing hard work not only to find out the answer to that question, but also to find more questions like it.

Just to be clear, in the first sentence above I didn't mean to say that the standard demos are useless -- far from it (see below). This was intended to be a challenging call to action to not be satisfied with demos alone, but for us as an industry to imagine and develop compelling mainstream end applications that are multicore- and manycore-scalable. (To make that clearer, I'm going to ditch and rewrite the first sentence above for the Effective Concurrency book.)

The standard demos are indeed important -- not only as proofs of concept, that the technology really does enable scalable parallel code, but at least as importantly as helpful tools in helping us to understand how a given parallel technology or runtime works.

To understand concurrency mechanics/characteristics

For example, consider a standard Mandelbrot-rendering demo, but with the twist that each worker thread (core) renders its portion of the work in a different color. On a traditional runtime with static scheduling, some workers with easy-to-compute sections will be done early and wait idly while the other workers finish their harder-to-compute sections, and we can see visually that each colored section is the same size and some colored sections appear faster than others. But on a runtime with dynamic scheduling, and especially one that supports Cilk-style work stealing, we get efficient load balancing where workers who are assigned "easy" sections and are done early can contribute to remaining work in harder-to-compute areas -- and visually some sections fill in with one color but then the same color starts to add to other yet-unfinished sections. The bands of color let us see which worker did what work and helped out in what other areas, and the overall visual progress of the whole image lets us see that the system as a whole is doing useful work the whole time. So the colored Mandelbrot demo is a very useful tool to let us understand what's going on quickly and clearly, in a way that presenting the results in a numerical table can't.

To illustrate a path to future applications

Similarly, ray-tracing may well make multicore and manycore CPUs the future of photorealistic graphics in a way that may not be applicable to standard GPUs (time will tell). As shown in the blogs below, ray-tracing makes a qualitative difference in the nature of lighting models. But can't we do this already with GPUs? Interestingly, not necessarily; ray-tracing seems to represent an algorithm that is hard to accelerate with GPUs with limited abilities to do the fine-grain scheduling that runtimes based on techniques like work stealing are well suited to do. Some links:

Yes, demos are useful

My point in the original quote above (which I see I could have stated more clearly) was simply this: Once we've achieved the demos, we shouldn't sit back and declare victory. The demos aren't the end goal; we still need the applications.

Concurrency demos are useful to help prove a technology can scale and to understand how it works, and some of them show potentially fruitful and exciting paths to real and compelling manycore-exploiting applications, but it's still up to us as an industry to continue to imagine and build those applications. I believe that we can and will.

Effective Concurrency: Going Superlinear

Wed, 30 Jan 2008 22:27:25 GMT

The latest Effective Concurrency column, "Going Superlinear", just went live on DDJ's site, and will also appear in the print magazine. From the article:

We spend most of our scalability lives inside a triangular box, shown in Figure 1. It reminds me of the early days of flight: We try to lift ourselves away from the rough ground of zero scalability and fly as close as possible to the cloud ceiling of linear speedup. Normally, the Holy Grail of parallel scalability is to linearly use P processors or cores to complete some work almost P times faster, up to some hopefully high number of cores before our code becomes bound on memory or I/O or something else that means diminishing returns for adding more cores. As Figure 1 illustrates, the traditional shape of our "success" curve lies inside the triangle.
Sometimes, however, we can equip our performance plane with extra tools and safely break through the linear ceiling into the superlinear stratosphere. So the question is: "Under what circumstances can we use P cores to do work more than P times faster?" There are two main ways to enter that rarefied realm:

Do disproportionately less work.
Harness disproportionately more resources.

This month and next, we'll consider situations and techniques that fall into one or both of these categories. ...

I hope you enjoy it.

Finally, here are links to previous Effective Concurrency columns (based on the dates they hit the web, not the magazine print issue dates):

July 2007	The Pillars of Concurrency
August 2007	How Much Scalability Do You Have or Need?
September 2007	Use Critical Sections (Preferably Locks) to Eliminate Races
October 2007	Apply Critical Sections Consistently
November 2007	Avoid Calling Unknown Code While Inside a Critical Section
December 2007	Use Lock Hierarchies to Avoid Deadlock
January 2008	Break Amdahl's Law!
February 2008	Going Superlinear

Effective Concurrency: Break Amdahl's Law!

Fri, 18 Jan 2008 00:10:30 GMT

The latest Effective Concurrency column, "Break Amdahl's Law!", just went live on DDJ's site, and will also appear in the print magazine. From the article:

Back in 1967, Gene Amdahl famously pointed out what seemed like a fundamental limit to how fast you can make your concurrent code: Some amount of a program's processing is fully "O(N)" parallelizable (call this portion p), and only that portion can scale directly on machines having more and more processor cores. The rest of the program's work is "O(1)" sequential (s). [1,2] Assuming perfect use of all available cores and no parallelization overhead, Amdahl's Law says that the best possible speedup of that program workload on a machine with N cores is given by

Note that, as N increases to infinity, the best speedup we can ever get is (s+p)/s. Figure 1 illustrates why a program that is half scalably parallelizable and half not won't scale beyond a factor of two even given infinite cores. Some people find this depressing. They conclude that Amdahl's Law means there's no point in trying to write multicore- and manycore-exploiting applications except for a few "embarrassingly parallel" patterns and problem domains with essentially no sequential work at all.
Fortunately, they're wrong. If Amdahl's Game is rigged, well then, to paraphrase a line from the movie WarGames: The only way to win is not to play. ...

I hope you enjoy it.

Finally, here are links to previous Effective Concurrency columns (based on the dates they hit the web, not the magazine print issue dates):

July 2007	The Pillars of Concurrency
August 2007	How Much Scalability Do You Have or Need?
September 2007	Use Critical Sections (Preferably Locks) to Eliminate Races
October 2007	Apply Critical Sections Consistently
November 2007	Avoid Calling Unknown Code While Inside a Critical Section
December 2007	Use Lock Hierarchies to Avoid Deadlock

Effective Concurrency: Use Lock Hierarchies to Avoid Deadlock

Wed, 12 Dec 2007 00:05:55 GMT

The latest Effective Concurrency column, "Use Lock Hierarchies to Avoid Deadlock", just went live on DDJ's site, and will also appear in the print magazine. From the article:

... The only way to eliminate such a potential deadlock is to make sure that all mutexes ever held at the same time are acquired in a consistent order. But how can we ensure this in a way that will be both usable and correct? For example, we could try to figure out which groups of mutexes might ever be held at the same time, and then try to define pairwise ordering rules that cover each possible combination. But that approach by itself is prone to accidentally missing unexpected combinations of locks; and even if we did it perfectly, the result would still be at best "DAG spaghetti"—a directed acyclic graph (DAG) that nobody could comprehend as a whole. And every time we want to add a new mutex to the system, we would have to find a way fit it into the DAG without creating any cycles.
We can do better by directly exploiting the knowledge we already have about the structure of the program to regularize the mess and make it understandable. ...

I hope you enjoy it.

Finally, here are links to previous Effective Concurrency columns (based on the dates they hit the web, not the magazine print issue dates):

July 2007	The Pillars of Concurrency
August 2007	How Much Scalability Do You Have or Need?
September 2007	Use Critical Sections (Preferably Locks) to Eliminate Races
October 2007	Apply Critical Sections Consistently
November 2007	Avoid Calling Unknown Code While Inside a Critical Section

Parallel Computing Releases at Microsoft

Sun, 02 Dec 2007 02:11:57 GMT

For those of you who may be interested in concurrency for Microsoft platforms, and .NET in particular, I'm happy to report some fresh announcements:

MSDN has launched a Parallel Computing developer center. This is a section of the MSDN site focused on "providing information, ideas, community, and technology to developers to make it easier to write programs that perform and scale well on parallel hardware."
You can download and try a CTP "preview" of the .NET Parallel Extensions (PFX). These compile and run, but remember they're CTP quality. PFX currently has two major parts:
- PLINQ: Parallel Language Integrated Query, a parallel version of LINQ with extensions like .AsParallel.
- TPL: Task Parallel Library with extensions like Parallel.For loops.
There's also a PFX Team Blog.

PFX is for .NET concurrency development, but of course we are (and personally I am) working on native development tools, including for C++ specifically, that are at least as exciting. Stay tuned here for future news. In the meantime, enjoy these bits and the resources and discussion on the Parallel Computing developer center and forums.

The Concurrency Land Rush: 2007-20??

Sun, 02 Dec 2007 02:04:40 GMT

Every time that we experience a "wave" in which the industry takes a programming paradigm that's been growing in a niche, and brings it to the mainstream, we go through similar phases:

A land rush phase during which vendors try to stake out their turf. The market sees an explosive proliferation of products trying to enable mainstream developers to work in the new paradigm and at the same time to differentiate themselves from each other. This phase always takes multiple years, and multiple major releases of many products, consumed at first mainly by early adopters and then, as products mature, broadly across the marketplace.
A shakeout phase as, eventually, the market sifts through the products, selects major winners, and realigns itself around them.

We (the software industry) have done it all before for technologies like OO and GUIs, and now we're going to do it for concurrency.

Starting in 2005, companies started to talk concurrency and to launch internal efforts. But only this year, in 2007, has our industry formally entered the concurrency wave's land rush phase by starting to field real products and preview releases. We're starting to see initial steps toward candidate mainstream-accessible products in releases like Intel's Threading Building Blocks and Software Transactional Memory prototype compiler, and Microsoft's just-announced and downloadable .NET Parallel Extensions (PFX) including CTP-level support for Parallel LINQ (PLINQ) and the Task Parallel Library.

True, the concurrency landscape has lots of existing tools. So did OO (e.g., Simula) and GUIs (e.g., the Win16 C API) long before they became widely accessible to developers in general. Concurrency's "Simulas and Win16s" include Thread classes and OpenMPI for doing work asynchronously, to OpenMP for fast parallel computation, to some pre-fab lock-free container classes, to limited race detectors and very basic thread profilers. But today's tools are still what you'd expect to see in a niche market: Good enough for highly-trained experts to deliver real products, but not easy enough and not integrated enough across the software stack and tool chains to be broadly adopted by mainstream developers.

Just as the OO mainstream land rush was fueled by new and updated tools like Smalltalk and Objective-C and C++ and Java offerings, and the GUI land rush was fueled by MFC and OWL and Cocoa and Visual Basic and Delphi, we're starting to see new and existing companies bringing lots of new and updated offerings across the entire software stack and ecosystem. Expect to see lots of new and updated/extended offerings of:

Languages and frameworks
Runtimes and operating systems
Debuggers and profilers and program analysis tools
Component wizards and IDE integration
Books and courses and conferences

These are the just beginning. Much more will come, from those same companies and others. Expect at least dozens of major product announcements and releases across the industry, before the toolset expansion phase is fully underway and approaching some maturity. We the industry have undertaken to bring concurrency to the mainstream, and as with OO and GUIs it will take multiple years, and multiple major releases, across the industry on all platforms.

As I write this, Seattle's first snowfall of the season is gently descending outside my window. It readily puts one in mind of Frost: We have promises to keep, and miles to go before we sleep.

Concurrency Town Hall: On the web, this Monday, December 3

Sat, 01 Dec 2007 00:30:48 GMT

Earlier this fall, James Reinders and I each gave concurrency webcast as part of Intel's fall webcast series. On Monday, James and I are going to be following that up with a virtual Town Hall panel discussion on concurrency, with Dr. Dobb's editor Jon Erickson as our moderator. Should be cool. And you are invited to attend.

Here are the coordinates:

Date: Monday, December 3, 2007
Time: 9:00-10:00am U.S. Pacific Time
Registration: http://www.life20.net/intel1reg.php
Web simulcast (doesn't require Second Life): http://www.slcn.tv

I expect that most people will be watching the event via the live simulcast on Second Life Cable Network. Use that if you're not a Second Life member, or if you are a member but can't get in there because the SL servers are expected to reach their maximum capacity for a single event.

There's also a network breakfast before the town hall portion. Here's the full description, as it appears on Intel's site:

SOFTWARE AND THE CONCURRENCY REVOLUTION: DESIGNING FOR MULTIPLE CORES

A virtual Town Hall held in Second Life by Intel Software Network and Dr. Dobb’s Journal
December 3, 2007 8:00 AM – 11:00 AM Pacific Time (11:00 AM – 1:00 PM ET) on Intel and Dr Dobb’s Islands.
Meet Intel and Industry experts, learn about parallel programming and concurrency trends, let your voice be heard.
This half day event will begin with a networking breakfast on Dr. Dobbs Island where you will have the ability to meet some of Intel’s best engineers. Tim Mattson (Intel Principal Engineer, Designer of the 80 Core test chip parallel application and one of the creator’s of Open MP*) will give a brief introduction on our transition to a many-core world.
Following breakfast, attendees will adjourn to Intel Island for the virtual town hall. This event will be moderated by Jonathan Erickson (Editorial Director, Dr. Dobb's) and will feature Herb Sutter (Architect, Microsoft, and chair of the ISO C++ Standards committee) and James Reinders (Chief Evangelist and Threading Guru for Intel Software Products) who will debate and discuss issues involved in realizing the promise of parallelization. As in any town Hall, your input will be vital.
After the town Hall, Peretz Stine of Intel Island and Rissa Maidstone of Dr. Dobbs will lead tours of their respective islands.
Schedule for December 3, 2007:
• 8:00-9:00 AM SLT – Networking Breakfast with Tim Mattson
• 9:00-10:00 AM SLT – Town Hall Meeting with Jon Erickson, James Reinders and Herb Sutter
• 10:00-11:00 AM SLT – Tour of Intel and Dr. Dobbs Islands
You must register to reserve a place at this event: http://www.life20.net/intel1reg.php
This event will be simulcast live on Second Life Cable Network: http://www.slcn.tv

Effective Concurrency: Avoid Calling Unknown Code While Inside a Critical Section

Tue, 06 Nov 2007 19:41:46 GMT

The latest Effective Concurrency column, "Avoid Calling Unknown Code While Inside a Critical Section", just went live on DDJ's site, and will also appear in the print magazine. Here's a teaser from the article's intro:

Don't walk blindly into a deadly embrace...
Our world is built on modular, composable software. We routinely expect that we don't need to know about the internal implementation details of a library or plug-in to be able to use it correctly.
The problem is that locks, and most other kinds of synchronization we use today, are not modular or composable. That is, given two separately authored modules, each of which is provably correct but uses a lock or similar synchronization internally, we generally can't combine them and know that the result is still correct and will not deadlock. There are only two ways to combine such a pair of lock-using modules safely: ...

I hope you enjoy it.

Finally, here are links to previous Effective Concurrency columns (based on the dates they hit the web, not the magazine print issue dates):

July 2007	The Pillars of Concurrency
August 2007	How Much Scalability Do You Have or Need?
September 2007	Use Critical Sections (Preferably Locks) to Eliminate Races
October 2007	Apply Critical Sections Consistently

Effective Concurrency: Apply Critical Sections Consistently

Wed, 10 Oct 2007 23:25:42 GMT

The latest Effective Concurrency column, "Apply Critical Sections Consistently", just went live on DDJ's site, and will also appear in the print magazine. Here's a teaser from the article's intro:

The critical section is our One True Tool for guaranteeing mutual exclusion on mutable shared variables. ...
[But critical sections] must be applied consistently, and with the intended meanings. A program must ensure that every use of a mutable shared object is properly protected using exactly one of these mechanisms at any given point in its lifetime. Chaos can erupt if code tries to avoid or invert these meanings (e.g., trying to abuse taking a lock or reading an atomic variable as a "critical section exit" operation; see Example 3), or tries to use inconsistent synchronization techniques at the same time.

I hope you enjoy it.

Next month's article is already in post-production. It delves into what I think is a really interesting rule, both because it's widely ignored and because it's full of surprises: "Avoid Calling Unknown Code While Inside a Critical Section." I'll blog here when it hits the web about a month from now.

Finally, here are links to previous Effective Concurrency columns (based on the dates they hit the web, not the magazine print issue dates):

September 2007: Use Critical Sections (Preferably Locks) to Eliminate Races
August 2007: How Much Scalability Do You Have or Need?
July 2007: The Pillars of Concurrency

Effective Concurrency: Use Critical Sections (Preferably Locks) to Eliminate Races

Wed, 05 Sep 2007 20:36:08 GMT

"In a race, no one can hear you scream."

That's my tagline for the third Effective Concurrency column, "Use Critical Sections (Preferably Locks) to Eliminate Races." It just went live on DDJ's site, and will also appear in the print magazine.

This article focuses on two main things:

The detailed facts of life about why most or all bets are off if you have a data race. You really, really, really don't want to have any races in your code.
The commonality that unifies all synchronization constructs you've ever used or will use, from locking to lock-free styles to fences to transactional memory.

Here's the article's intro:

Everyone knows the basics of how to use locks:
mut.lock(); // acquire lock on x
... read/write x ...
mut.unlock(); // release lock on x
But why do locks, lock-free styles, and other synchronization techniques work at all, never mind interoperate well with each other and with aggressive optimizers that transform and reorder your program to make it run faster? Because every synchronization technique you've ever heard of must express, and every optimization that may ever be performed must respect and uphold, the common fundamental concept of a critical section. ...

I hope you enjoy it.

Next month's article is already in post-production. It follows directly from this one, and will be titled "Apply Critical Sections Consistently." I'll blog here when it hits the web about a month from now.

Finally, here are links to previous Effective Concurrency columns (based on the dates they hit the web, not the magazine print issue dates):

August 2007: How Much Scalability Do You Have or Need?
July 2007: The Pillars of Concurrency

Effective Concurrency: How Much Scalability Do You Have or Need?

Fri, 03 Aug 2007 16:18:34 GMT

The second Effective Concurrency column in DDJ just went live. It's titled "How Much Scalability Do You Have or Need?" and makes the case that there's more than just one important category of throughput scalability, and one size does not fit all. From the article:

In your application, how many independent pieces of work are ready to run at any given time? Put another way, how many cores (or hardware threads, or nodes) can your code harness to get its answers faster? And when should the answers to these questions not be "as many as possible"?

I hope you enjoy it.

Next month's article is already in post-production. It will be titled "Use Critical Regions (Preferably Locks) to Eliminate Races" and will hit the web about a month from now. One of the early questions it answers is, How bad can a race be? There's a hint in the article's tagline: "In a race no one can hear you scream..."

Finally, here are some links to last month's Effective Concurrency column and to a prior locking article of interest that provides a nice background motivation for the next few EC articles to come starting next month:

July 2007: The Pillars of Concurrency
March 2005: The Trouble With Locks

EC: A new column on Effective Concurrency

Tue, 03 Jul 2007 20:48:37 GMT

I'm pleased to say that I'm starting a new column on Effective Concurrency in DDJ, and the first installment just went live.

It's titled "The Pillars of Concurrency" and tries to make the case that we need to have a consistent mental model for talking about concurrency issues if we're going to make any serious headway in designing and using concurrent systems. In particular, as the article notes:

Have you ever talked with another developer about concurrency, and felt as though you were somehow speaking completely different languages? If so, you're not alone. You can see the confusion in our vocabulary...

Next month's article is already in post-production. It's titled "How Much Scalability Do You Have or Need?" and it'll be online about a month from now. I'll let you know here once it hits the web.

And who knows? If this newfangled essential-Items-at-3-to-5-pages-each format turns out to be popular, there just might eventually be a book here...

EC -10 days

Sun, 24 Jun 2007 21:08:42 GMT

More to come...

OGDC Talk Slides Online

Thu, 17 May 2007 23:40:50 GMT

I've been getting a fair number of requests for my slides from last week's keynote at OGDC. They're now available here.

Sutter's Mill: Concurrency

Concurrency Interview with DevX

New Course Available: Effective Concurrency

3-Day Seminar: Effective Concurrency

May 19-21, 2008Bellevue, WA, USADeveloped and taught by Herb Sutter

Effective Concurrency: Super Linearity and the Bigger Machine

How parallelism demos are useful

To understand concurrency mechanics/characteristics

To illustrate a path to future applications

Yes, demos are useful

Effective Concurrency: Going Superlinear

Effective Concurrency: Break Amdahl's Law!

Effective Concurrency: Use Lock Hierarchies to Avoid Deadlock

Parallel Computing Releases at Microsoft

The Concurrency Land Rush: 2007-20??

Concurrency Town Hall: On the web, this Monday, December 3

SOFTWARE AND THE CONCURRENCY REVOLUTION: DESIGNING FOR MULTIPLE CORES

Effective Concurrency: Avoid Calling Unknown Code While Inside a Critical Section

Effective Concurrency: Apply Critical Sections Consistently

Effective Concurrency: Use Critical Sections (Preferably Locks) to Eliminate Races

Effective Concurrency: How Much Scalability Do You Have or Need?

EC: A new column on Effective Concurrency

EC -10 days

OGDC Talk Slides Online

May 19-21, 2008
Bellevue, WA, USA
Developed and taught by Herb Sutter