Tag: library

The GNU Toolchain is a collection of programming tools produced by the GNU Project. The tools are often packaged together due to their common use for developing software applications, operating systems, and low-level software for embedded systems.

This blog is part of a regular series covering the latest changes and improvements in the components that make up this Toolchain. Apart from the announcement of new releases, however, the features described here are at the bleeding edge of software development in the tools. This does mean that it may be a while before they make it into production releases, and they might not be fully functional yet. But anyone who is interested in experimenting with them can build their own copy of the Toolchain and then try them out.

The GNU Toolchain is a collection of programming tools produced by the GNU Project. The tools are often packaged together due to their common use for developing software applications, operating systems, and low-level software for embedded systems.

This blog is part of a regular series covering the latest changes and improvements in the components that make up this Toolchain. Apart from the announcement of new releases, however, the features described here are at the bleeding edge of software development in the tools. This does mean that it may be a while before they make it into production releases, and they might not be fully functional yet. But anyone who is interested in experimenting with them can build their own copy of the Toolchain and then try them out.

The problem

C/C++ libraries expect to be able to change the internal implementation details of opaque data types from release to release since such a change has no external ABI consequences. If an opaque data type is placed in process-shared memory (when allowed by the standard) and shared with multiple processes, each process must ensure they are using exactly the same version of the library or they could fail in unexpected ways during library upgrades. The placement of opaque data types in process-shared memory is never allowed unless otherwise stated by the library documentation. For the GNU C Library (glibc) you may place pthread_mutex_t, pthread_cond_t, and sem_t in process-shared memory as allowed by POSIX. Failures using these types occur because a process started more recently may have a newer version of the library for the type and that version may have a different understanding of the internal details of the type. The problem has always been one for the developer to solve, but without help, this problem is so intractable as to make it difficult to robustly use opaque data types in process shared memory.

We will cover opaque data types, what they are, why you would use them, and how library upgrades play into the problem, and what might be done by the application developer.

Several Red Hat engineers recently attended the JTC1/SC22/WG21 C++ Standards Committee meetings in Oulu, Finland. This post focuses on the sessions of SG1 (the standards committee sub-group 1 – for concurrency and parallelism) as well as on coroutines-related sessions. Jason already gave an overview of the meeting in his post.

SG1 prioritized proposals and issues affecting the (expected) C++17 standard, followed by proposals targeting the Concurrency TS or a future revision of the Parallelism TS. We also made some progress in the space of coroutines.

Several Red Hat engineers recently attended the JTC1/SC22/WG21 C++ Standards Committee meetings in March 2016 in Jacksonville, Florida, USA. This post focuses on the sessions of SG1 (the standards committee sub-group 1 – for concurrency and parallelism) and on several proposals related to coroutines.

This means that C++17 will offer support for several parallel algorithms, provided that the standard is approved in the remaining stages of the ISO voting process. If approved, this will make utilizing parallelism easier for many users – e.g., a parallel “for-each” loop, as a simple example.

Several 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.

Several 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.