C++ and Beyond: About 2/3 Full

C++ and Beyond 2010 (October 24-27) is filling up quickly. As of this writing, nearly 40 of the 60 places have been taken since registration opened last month.

If you’re thinking of registering, it would probably be good to do it soon. 60 attendees is a hard limit; as I’ve written before, we want to have lots of face time with individual attendees. So once we hit 60, registration will close, although we’ll probably set up a waiting list for those of you that don’t quite make it into the first 60 so that you’ll get dibs if there are any cancellations.

I’m looking forward to seeing many of you in beautiful Snoqualmie, WA, USA this fall.

Effective Concurrency: Associate Mutexes with Data to Prevent Races

This month’s Effective Concurrency column, Associate Mutexes with Data to Prevent Races”, is now live on DDJ’s website.

From the article:

Come together: Associate mutexes with the data they protect, and you can make your code race-free by construction

Race conditions are one of the worst plagues of concurrent code: They can cause disastrous effects all the way up to undefined behavior and random code execution, yet they’re hard to discover reliably during testing, hard to reproduce when they do occur, and the icing on the cake is that we have immature and inadequate race detection and prevention tool support available today.

The holy grail of the Consistency pillar is to make a concurrent program race-free and deadlock-free by construction. … This article shows how to achieve the "race-free by construction" grail via sound engineering, with automatic and deterministic race identification at test time based on code coverage alone.

I hope you enjoy it. Finally, here are links to previous Effective Concurrency columns:

1 The Pillars of Concurrency (Aug 2007)

2 How Much Scalability Do You Have or Need? (Sep 2007)

3 Use Critical Sections (Preferably Locks) to Eliminate Races (Oct 2007)

4 Apply Critical Sections Consistently (Nov 2007)

5 Avoid Calling Unknown Code While Inside a Critical Section (Dec 2007)

6 Use Lock Hierarchies to Avoid Deadlock (Jan 2008)

7 Break Amdahl’s Law! (Feb 2008)

8 Going Superlinear (Mar 2008)

9 Super Linearity and the Bigger Machine (Apr 2008)

10 Interrupt Politely (May 2008)

11 Maximize Locality, Minimize Contention (Jun 2008)

12 Choose Concurrency-Friendly Data Structures (Jul 2008)

13 The Many Faces of Deadlock (Aug 2008)

14 Lock-Free Code: A False Sense of Security (Sep 2008)

15 Writing Lock-Free Code: A Corrected Queue (Oct 2008)

16 Writing a Generalized Concurrent Queue (Nov 2008)

17 Understanding Parallel Performance (Dec 2008)

18 Measuring Parallel Performance: Optimizing a Concurrent Queue (Jan 2009)

19 volatile vs. volatile (Feb 2009)

20 Sharing Is the Root of All Contention (Mar 2009)

21 Use Threads Correctly = Isolation + Asynchronous Messages (Apr 2009)

22 Use Thread Pools Correctly: Keep Tasks Short and Nonblocking (Apr 2009)

23 Eliminate False Sharing (May 2009)

24 Break Up and Interleave Work to Keep Threads Responsive (Jun 2009)

25 The Power of “In Progress” (Jul 2009)

26 Design for Manycore Systems (Aug 2009)

27 Avoid Exposing Concurrency – Hide It Inside Synchronous Methods (Oct 2009)

28 Prefer structured lifetimes – local, nested, bounded, deterministic (Nov 2009)

29 Prefer Futures to Baked-In “Async APIs” (Jan 2010)

30 Associate Mutexes with Data to Prevent Races (May 2010)

The “You Call This Journalism?” Department

The Inquirer isn’t normally this silly, and it isn’t even April 1. Nick Farrell writes:

Why Apple might regret the Ipad [sic]

THE IPAD HAS DOOMED Apple, according to market anlaysts [sic] that are expecting the tablet to spell trouble for its maker. … Rather than killing off the netbook, the Ipad [sic] is harming sales of the Ipod [sic] and Macbooks… if the analysts are right the Ipad [sic] has killed the Ipod [sic] Touch.

This is just silly, for four reasons. Three are obvious:

  • The iPod Touch fits in your pocket and can be easily with you all the time. Nothing bigger can ever kill it, but only replace it for a subset of users who don’t need in-pocket portability. (Besides, even if all iPod Touch buyers bought an iPad instead, the latter is more expensive and so the correct term would be not “kill” but “upsell”.)
  • The laptop has a real keyboard and full applications. Nothing not full-featured can ever kill it, but only replace it for a subset of users who don’t need the richer experience and applications.
  • Even if it was killing the other business outright, which it isn’t, it’s always better to eat your own lunch than wait for a competitor to do it.

And the fourth reason it’s silly? Let’s be very clear: The iPad has sold 1 million units in its first 28 days. At $500-700 a pop, that means the iPad is becoming a new billion-dollar business in two months.

Nick, I don’t think “regret” is the word you’re looking for.

May 12 Webinar on Multicore Parallelism

Next week, I’m giving a webinar with Intel’s James Reinders, and we’ll be available for a live Q&A session with you at the end:

Five Years Since Free Lunches: Making Use of Multicore Parallelism

May 12, 2010 at 8 a.m. PT/11 a.m. ET.

Reflecting on the five years since "The Free Lunch is Over" article and the arrival of multicore processors, Sutter and Reinders will talk about the keys to making effective use of multicore parallelism. Programmers are in the midst of an evolution that takes time, and we are still in the early days. Sutter and Reinders share expert advice on how to view this transition, and the keys to getting it right—including a three-pillar model for concurrency, the need to maximize the number of tasks expressed in a program, and how abstractions encourage "many task" programming, while allowing overheads to be driven down under-the-covers.

James and I had a lot of fun recording the video portion about a month ago, and I hope you enjoy it. We touched on everything from the three basic pillars I’ve written about before but that bear repeating, to whether functional languages will take the world by storm (perhaps surprisingly, yes… but why and how?), to the perennial question of “how finely should I decompose my work to run it well in parallel” (and I really must write an EC article about this).

Afterwards, James and I will be on the phone to take your questions. If you have a particular point you want to ask about, why not take the time now to prepare a well-crafted and concise question in advance? I’m looking forward to hearing from many of you.

Links I enjoyed this week: Flash and HTML5

These are the two best links I’ve read in the wake of the Flash and HTML5 brouhaha(s). They discuss other informative points too, but their biggest value lies in discussing three things, to which I’ll offer the answers that make the most sense to me:

  • What is the web, really? “The web” is the cross-linked content, regardless of what in-browser/PC-based/phone-based generator/viewer/app is used to produce it and/or consume it.
  • Does web == in-browser? No. Native apps can be web apps just as much so as in-browser ones, and increasingly many native apps are web apps. Conversely, not everything that runs in a browser is part of the web, even though most of them are for the obvious historical reasons.
  • Is it necessary/desirable/possible to make in-browser apps be like native apps? No, maybe, and maybe. The jury is still out, but at the moment developers are still trying while some pundits keep decrying.

Here are the two articles.

Understand the Web (Ben Ward)

This rambly piece needs serious editing, but is nevertheless very informative. Much of the debate about Flash and/or HTML5 conflates two things: the web, and application development platforms. They aren’t the same thing, and in fact are mostly orthogonal. From the article:

Think about that word; ‘web’. Think about why it was so named. It’s nothing to do with rich applications. Everything about web architecture; HTTP, HTML, CSS, is designed to serve and render content, but most importantly the web is formed where all of that content is linked together. That is what makes it amazing, and that is what defines it.

… [in the confused Flash and HTML5 debates] We’re talking about two very different things: The web of information and content, and a desire for a free, cross-platform Cocoa or .NET quality application framework that runs in the browsers people already use.

On a different note, speaking of the desire for super-rich in-browser apps, he adds:

Personally, aside from all of this almost ideological disagreement over what the web is for, and what you can reasonably expect it to be good at, I honestly think that ‘Desktop-class Web Applications’ are a fools folly. Java, Flash, AIR and QT demonstrate right now that cross-platform applications are always inferior to the functionality and operation of the native framework on a host platform. Steve Jobs is right in his comments that third-party frameworks are an obstacle to native functionality.

HTML5 and the Web (Tim Bray)

Again, what “the web” is – and it has nothing specifically to do with HTML. From the article:

The Web is a tripod, depending critically on three architectural principles:

  • Pieces of the Web, which we call Resources, are identified by short strings of characters called “URIs”.

  • Work is accomplished by exchanging messages, which comprise metadata and representations of Resources.

  • The representations are expressed in a number of well-defined data formats; you can count on the message data to tell you which one is in use. It is essential that some of the representation formats be capable of containing URIs. The “Web” in WWW is that composed by the universe of Resources linked by the URIs in their representations.

That’s all. You notice that there’s nothing there that depends crucially on any flavor of HTML. Speaking only for myself, an increasingly large proportion of my Web experience arrives in the form of feed entries and Twitter posts; not HTML at all, but 100% part of the Web.

On Flash · This may be a side-trip, but anyhow: I entirely loathe Flash but by any definition it’s part of the Web. It works just fine as a resource representation and it can contain URI hyperlinks.

Native Applications · A large proportion of the native applications on iPhone, and on Android, and on Windows, and on Mac, and on Linux, are Web applications. They depend in a fundamental way on being able to recognize and make intelligent use of hyperlinks and traverse the great big wonderful Web.

… So whatever you may think of native applications, please don’t try to pretend that they are (or are not) necessarily good citizens of the Web. Being native (or not) has nothing to do with it.

Good stuff.