C++ and Beyond

Here’s another deep session for C&B 2012 on August 5-8 – if you haven’t registered yet, register soon. We got a bigger venue this time, but as I write this the event is currently almost 75% full with five weeks to go.

I know, I’ve already posted three sessions and a panel. But there’s just so much about C++11 to cover, so here’s a fourth brand-new session I’ll do at C&B 2012 that goes deeper on its topic than I’ve ever been willing to go before.

atomic<> Weapons: The C++11 Memory Model and Modern Hardware

This session in one word: Deep.

It’s a session that includes topics I’ve publicly said for years is Stuff You Shouldn’t Need To Know and I Just Won’t Teach, but it’s becoming achingly clear that people do need to know about it. Achingly, heartbreakingly clear, because some hardware incents you to pull out the big guns to achieve top performance, and C++ programmers just are so addicted to full performance that they’ll reach for the big red levers with the flashing warning lights. Since we can’t keep people from pulling the big red levers, we’d better document the A to Z of what the levers actually do, so that people don’t SCRAM unless they really, really, really meant to.

This session covers:

• The facts: The C++11 memory model and what it requires you to do to make sure your code is correct and stays correct. We’ll include clear answers to several FAQs: “how do the compiler and hardware cooperate to remember how to respect these rules?”, “what is a race condition?”, and the ageless one-hand-clapping question “how is a race condition like a debugger?”
• The tools: The deep interrelationships and fundamental tradeoffs among mutexes, atomics, and fences/barriers. I’ll try to convince you why standalone memory barriers are bad, and why barriers should always be associated with a specific load or store.
• The unspeakables: I’ll grudgingly and reluctantly talk about the Thing I Said I’d Never Teach That Programmers Should Never Need To Now: relaxed atomics. Don’t use them! If you can avoid it. But here’s what you need to know, even though it would be nice if you didn’t need to know it.
• The rapidly-changing hardware reality: How locks and atomics map to hardware instructions on ARM and x86/x64, and throw in POWER and Itanium for good measure – and I’ll cover how and why the answers are actually different last year and this year, and how they will likely be different again a few years from now. We’ll cover how the latest CPU and GPU hardware memory models are rapidly evolving, and how this directly affects C++ programmers.
• Coda: Volatile and “compiler-only” memory barriers. It’s important to understand exactly what atomic and volatile are and aren’t for. I’ll show both why they’re both utterly unrelated (they have exactly zero overlapping uses, really) and yet are fundamentally related when viewed from the perspective of talking about the memory model. Also, people keep seeing and asking about “compiler-only” memory barriers and when to use them – they do have a valid-though-rare use, but it’s not the use that most people are trying to use them for, so beware!

For me, this is going to be the deepest and most fun C&B yet. At previous C&Bs I’ve spoken about not only code, but also meta topics like design and C++’s role in the marketplace. This time it looks like all my talks will be back to Just Code. Fun times!

Here a snapshot of the list of C&B 2012 sessions so far:

Universal References in C++11 (Scott)
You Don’t Know [keyword] and [keyword] (Herb)
Convincing Your Colleagues (Panel)
Initial Thoughts on Effective C++11 (Scott)
Modern C++ = Clean, Safe, and Faster Than Ever (Panel)
Error Resilience in C++11 (Andrei)
C++ Concurrency – 2012 State of the Art (and Standard) (Herb)
C++ Parallelism – 2012 State of the Art (and Standard) (Herb)
Secrets of the C++11 Threading API (Scott)
atomic<> Weapons: The C++11 Memory Model and Modern Hardware (Herb)

It’ll be a blast. I hope to see many of you there. Register soon.

I wanted to give a gentle reminder to everyone that our special pricing for C++ and Beyond room rates at Grove Park Inn are only available through July 6 -  one short week from now.

If you have been procrastinating on making hotel reservations, now is the time. We got a GREAT deal on the hotel rooms, so if you don’t make the reservations by July 6, you may end up paying a lot more for your room.

If you want to attend and get the special room rates, but you won’t be able to get the registration paperwork done by the 6th, you can make your hotel reservation before you’ve signed up for C&B. No need to wait and miss out!

Visit the Venue Page for details on how to book your room.

See you there in August ~

Lisa

Photo source: Prashant Shrestha

Most parts of the C++11 threading API are pretty straightforward.   You look up the specs for the component you want to use, you read through the information, and off you go.  Piece of cake.  Usually.

But sometimes you can’t find what you’re looking for.  How do you set a thread’s priority or affinity?  How can you poll for the readiness of a future?  When should you notify_all instead of doing a notify_one?

Or maybe your code’s behavior is, shall we say?, not quite what you had in mind.  You pass data by reference to an asynchronously running function, but the function doesn’t see changes you make to the data, yet if you replace the reference with a pointer, everything works fine.  You write a function that spawns a thread and returns, but terminate keeps getting called.  You invoke a function asynchronously, but you find that sometimes (yet not always) it seems to be trashing your thread-local data.

Or possibly you’re perplexed when you make seemingly innocuous changes to your code, yet that opens the door to the wizard of weird.  For example, you replace a shared_future with a “normal” future, because you find that only one thread really needs to use the future, but your program starts doing strange things.  You replace a call to async with the “equivalent” code using packaged_task, but the behavior is far from equivalent.  You replace a call to async with the “equivalent” execution of a function on a thread, but your program intermittently crashes. What gives?

In this talk, I explore some of the lesser-known and easily-overlooked aspects of the C++11 threading API.  The goal isn’t to set you up as a master of API trivia, it’s to prepare you for the transition from programming “Hello Threads” to really knowing what’s going on.

Scott