triegelrh

Recent Posts

Red Hat at the ISO C++ Standards Meeting (July 2017): Parallelism and Concurrency

Several Red Hat engineers attended the JTC1/SC22/WG21 C++ Standards Committee meetings in July 2017. This post focuses on the sessions of SG1, the study group on parallelism and concurrency.  We discussed several synchronization-related proposals, improvements for futures, and, of course, executors. Also, I proposed a few steps that the SG1 community could take to get more efficient in how it conducts its work, which are all inspired by how successful open source projects work.

Continue reading “Red Hat at the ISO C++ Standards Meeting (July 2017): Parallelism and Concurrency”

Share

Red Hat at the ISO C++ Standards Meeting (March 2017): Parallelism and Concurrency

Several Red Hat engineers attended the JTC1/SC22/WG21 C++ Standards Committee meetings in March 2017. This post focuses on the sessions of SG1, the study group on parallelism and concurrency. The major topics of work of the week were (1) further polishing of the parallel algorithms in the C++17 draft, (2) making progress on the executors proposal (which provides mechanisms to control how parallel work is executed, for example on which resources), and (3) continuing work on proposals targeting the Concurrency Technical Specification version 2. We also discussed an important aspect of enabling standard C++ code to execute on GPUs, which is a topic that several people in SG1 have a lot of interest in — I certainly do, for example.

Continue reading “Red Hat at the ISO C++ Standards Meeting (March 2017): Parallelism and Concurrency”

Share

Red Hat at the ISO C++ Standards Meeting (May 2015): Parallelism and Concurrency

gnu logoSeveral Red Hat engineers attended the JTC1/SC22/WG21 C++ Standards Committee meetings in May 2015 at Lenexa, Kansas, USA.  This post focuses on the sessions of SG1, the study group on parallelism and concurrency.

Finishing the Technical Specifications (TSes) was one major point on the agenda of SG1. The Parallelism TS (see this draft) and the Transactional Memory TS (see this draft) have been finalized for publication, and the Concurrency TS and has been made ready for a vote and feedback by the National Bodies. GCC does not yet support those TSes but already has the main functionality required by the Transactional Memory TS through implementing a previous specification of the language constructs for transactions. SG1 is continuing to adding features in those areas, but these will target a version 2 of each of these TSes.

Continue reading “Red Hat at the ISO C++ Standards Meeting (May 2015): Parallelism and Concurrency”

Share

Recent improvements to concurrent code in glibc

gnu logoIn this post, I will give examples of recent improvements to concurrent code in glibc, the GNU C library, in the upstream community project. In other words, this is code that can be executed by multiple threads at the same time and has to coordinate accesses to shared data using synchronization. While some of these improvements are user-visible, many of them are not but can serve as examples of how concurrent code in other code bases can be improved.

One of the user-visible improvements is a new implementation of Pthreads semaphores that I contributed. It puts less requirements on when a semaphore can be destructed by a program. Previously, programs had to wait for all calls to sem_wait or sem_post to return before they were allowed to call sem_destroy; now, under certain conditions, a thread that returned from sem_wait can call sem_destroy immediately even though the matching sem_post call has woken this thread but not returned yet. This works if, for example, the semaphore is effectively a reference counter for itself; specifically, the program must still ensure that there are no other concurrent, in-flight sem_wait calls or sem_post calls that are yet to increment the semaphore. The new semaphore implementation is portable code due to being based on C11 atomic operations (see below) and replaces several architecture-specific implementations.

Continue reading “Recent improvements to concurrent code in glibc”

Share

Red Hat at the ISO C++ Standards Meeting (Nov 2014): Parallelism and Concurrency

gnu logoSeveral Red Hat engineers attended the JTC1/SC22/WG21 C++ Standards Committee meetings in November 2014 at Urbana-Champaign, IL, USA.  This post focuses on the sessions of SG1, the study group on parallelism and concurrency, which met for the whole week to discuss proposals and work on the technical specifications (TS) for both parallelism and concurrency.

SG1 mostly worked on finalizing the first revision of the Parallelism TS, and continued working on accepting proposals into the Concurrency TS. The Transactional Memory proposal is also making progress on becoming a TS.

Continue reading “Red Hat at the ISO C++ Standards Meeting (Nov 2014): Parallelism and Concurrency”

Share

Red Hat at the ISO C++ Standards Meeting (June 2014): Parallelism and Concurrency

Recently Red Hat sent several representatives to the JTC1/SC22/WG21 C++ Standards Committee meetings, which were held in June 2014 at the University of Applied Sciences in Rapperswil, Switzerland.

As in past ISO C++ meetings, SG1, the study group on parallelism and concurrency, met for the whole week to discuss proposals and work on the technical specifications (TS) for both parallelism and concurrency.

Continue reading “Red Hat at the ISO C++ Standards Meeting (June 2014): Parallelism and Concurrency”

Share

C/C++ Programming Abstractions for Parallelism and Concurrency – Part 2

Welcome to part 2 of this two-part article on C/C++ Programming Abstractions for Parallelism and Concurrency.  If you missed Part 1, view it here.

Supporting task-based parallelism

Let us now switch from concurrency to parallelism. I already mentioned that C++11 and C11 provide support for creating threads that execute additional work in parallel or concurrently. However, these facilities are rather resource abstractions (i.e., for operating system threads) than abstractions aimed purely at parallelism. One target for the latter is often task-based parallelism, which allows programmers to split a part of a program into tasks (i.e., units of work). These tasks will run in parallel, but they can also depend on other tasks in which case a dependent task will not start executing until all it’s dependencies are fulfilled (e.g., until a prior task has finished generating output that constitutes input for the current task). This essentially creates a directed acyclic graph (DAG) of tasks; tasks that are not ordered in the DAG wrt. each other can execute in parallel.

So, how can programmers express that they want to run a parallel task? When managing threads explicitly using the thread abstractions (explicit threading for short), this may look like this:

try {
  auto task = std::thread(work); // Execute the work() function
  // ... Do something else ...
  task.join();
  // ... Use the task's result ...
}
catch (std::system_error e) { error_fallback(); }

We explicitly create a new thread and join the thread (i.e., wait for it to complete its work) at task dependencies. We need error handling and a fallback in case we cannot create another thread for some reason.

Continue reading “C/C++ Programming Abstractions for Parallelism and Concurrency – Part 2”

Share