The CppCon 2015 conference program has been posted for the upcoming September conference. We’ve received requests that the program continue to be posted in “bite-sized” posts, a few sessions at a time, to make the 100+ sessions easier to absorb, so here is another set of talks. This series of posts will conclude once the entire conference program has been posted in this way.

The current processors have many cores. To use them well and safely for concurrent programming is not always easy.

The following interrelated CppCon 2015 talks tackle these issues and more.

In this post:

• Racing the file system
• Transactional Memory in Practice
• Single Threaded Functional to Massively Parellel Stochastic with AMP
• How to make your data structures wait-free for reads
• Parallel Program Execution using Work Stealing
• Executors for C++ - A Long Story

Racing the file system by Niall Douglas, Consultant for Hire, ned Productions Ltd

Almost every programmer knows about and fears race conditions on memory where one strand of execution may concurrently update data in use by another strand of execution, leading to an inconsistent and usually dangerous inconsistent read of program state. Almost every programmer therefore is aware of mutexes, memory ordering, semaphores and the other techniques used to serialise access to memory.

Interestingly, most programmers are but vaguely aware of potential race conditions on the filing system, and as a result write code which assumes that the filing system does not suddenly change out from underneath you when you are working on it. This assumption of a static filing system introduces many potential security bugs never mind ways of crashing your program, and of course creating data loss and corruption.

This workshop will cover some of the ways in which filing system races can confound, and what portable idioms and patterns you should employ to prevent misoperation, even across networked Samba shares. Finally, an introduction of the proposed Boost library AFIO will be made which can help application developers writing filing system race free code portably.

Transactional Memory in Practice by Brett Hall, Principal Software Engineer, Wyatt Technology

Transactional memory has been held up as a panacea for concurrent programming in some quarters. The C++ standardization committee is even looking at including it in the standard. But is it really a panacea? Has anyone used it in a shipping piece of software? There are scattered examples, mostly from the high-performance and super-computing realms. On the other end of the spectrum, at Wyatt Technology we've been using transactional memory in a desktop application that does data acquisition and analysis for the light-scattering instruments we build. That application is called Dynamics and we've been using a software transactional memory system in it for four years now. This talk will detail how our system works, how well it worked, and what pitfalls we've run into. Prior experience with transactional memory will not be assumed, though it would help if you have experience programming threads with locks and an open mind about alternatives and why we're looking for them.

Single Threaded Functional to Massively Parellel Stochastic with AMP by Kevin Carpenter, Software Engineer, Carpenter Systems LLC

Come with us as we take a legacy MFC financial modelling application that is largely function in design and transform it to something new. We will take a portion of this large financial simulation application and change its single threaded ways into parallel processing stochastic model. Transforming single class’s with a hodge-podge of functions into an object oriented parallel design using c++ amp and implementing Stochastic modelling methodology. Aside from focusing on the key portions of converting functional single threaded code to a parallel design we will also touch on some of the details of financial modeling for interest rate risk.

How to make your data structures wait-free for reads by Pedro Ramalhete, Cisco

In this talk we will describe a new concurrency control algorithm with Blocking write operations and Wait-Free Population Oblivious read operations, which we named the Left-Right algorithm.

We will show a new pattern where this algorithm is applied, which requires using two instances of a given resource, and can be used for any data structure, allowing concurrent access to it similarly to a Reader-Writer lock, but in a non-blocking manner for reads, including safe memory management without needing a Garbage Collector.

Parallel Program Execution using Work Stealing by Pablo Halpern, Mr, Intel Corp.

If you've used a C++ parallel-programming system in the last decade, you've probably run across the term "work stealing." Work stealing is a scheduling strategy that automatically balances a parallel workload among available CPUs in a multi-core computer, using computation resources with theoretical utilization that is nearly optimal. Modern C++ parallel template libraries such as Intel(R)'s TBB or Microsoft*'s PPL and language extensions such as Intel(R) Cilk(tm) Plus or OpenMP tasks are implemented using work-stealing runtime libraries.

Most C++ programmers pride themselves on understanding how their programs execute on the underlying machine. Yet, when it comes to parallel programming, many programmers mistakenly believe that if you understand threads, then you understand parallel runtime libraries. In this talk, we'll investigate how work-stealing applies to the semantics of a parallel C++ program. We'll look at the theoretical underpinnings of work-stealing, now it achieves near optimal machine utilization, and a bit about how it's implemented. In the process, we'll discover some pit-falls and how to avoid them. You should leave this talk with a deeper appreciation of how parallel software runs on real systems.

Previous experience with parallel programming is helpful but not required. A medium level of expertise in C++ is assumed.

Executors for C++ - A Long Story by Detlef Vollmann

Executors will be a base building block in C++ for asynchronous, concurrent and parallel work. The job of an executor is simple: run the tasks that are posted. So the first proposals for executors in C++ had a very simple interface. However, being a building block, the executor should provide an interface that's useful for all kind of higher level abstractions and needs to work together with different types of concurrency, like co-operative multi-tasking or GPU like hardware. This presentation will look at the evolution of the executor proposals for C++ and what they'll provide for normal application programmers.