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 ...
  // ... 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”


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

When writing parallel or multi-threaded programs, programmers have to deal with parallelism and concurrency. Both are related concepts but are not the same. In this article, we will review the differences between them and outline a few programming abstractions for both (in particular, atomic data types, Transactional Memory, and task-based parallelism). Red Hat Developer Toolset 1.1 ships with GCC-4.7, which provides (experimental) support for these particular features. Finally, a short outlook on future features proposed for inclusion in the C/C++ standards and considered for upstream GCC.

Concurrent execution refers to situations in which several (logical) processes or threads execute at the same time and are not guaranteed to be independent; for example, they could communicate with each other, wait for other threads to make progress, or could have to execute operations mutually exclusive with the execution of other threads’ operations. In contrast, parallel execution refers to several processes performing independent operations that, informally, do not have to consider what the other parallel parts are doing.

Nonetheless, parallelism is related to concurrency in that a typical parallel program will also contain concurrent pieces of code (e.g., to merge the results of parallel computations into a single output value). Also, to benefit from parallelism in hardware, concurrent code often tries to execute as much as possible in parallel (see Amdahl’s Law).

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


Sys Admins: Developers Asking for Unsupported ToolChains?

If you have ever worked as a system administrator, you are familiar with developers constantly wanting to use the latest toolchains even to the point of wanting to roll their own packages. Of course, the challenge is, if you are running a production environment, introducing change is always risky. If the change being introduced is from an unknown source, the risk is even higher. As a result, many admins rely on companies like Red Hat to provide them some assurances regarding the quality of the components underpinning the applications. However, a company like Red Hat also has an interest in only supporting tools that are known to be stable and fault-free (as much as anything can be). Sometimes this doesn’t meet the developers’ needs. As a result, Red Hat has introduced (currently in Beta) the Red Hat Software Collections bundle to try to find a happy medium.

All that being said, and arguably said before in press releases and the like :), there is another interesting use case for the software collections concept. Specifically, what about when the developers and the business have essentially abandoned an application? In other words, the application delivers on its promises to customers already, and, at this point in time, there is no desire to invest further resources in the application. Well, what does that mean for you System Admins? Well, generally, it means you get caught holding the bag having to maintain an older toolchain just to support the application.

Continue reading “Sys Admins: Developers Asking for Unsupported ToolChains?”


Software Collections Quickstart

As I discussed in an article entitled Red Enterprise Linux Release Speed, developers sometimes have a problem with how slow Red Hat’s Enterprise Linux releases new versions of software. Well, the good news is, Software Collections are here. Software Collections provide Red Hat Enterprise Linux users with newer versions of programming languages and server daemons like python, perl, ruby, php, mysql, mariadb, etc.

This is a quick start guide to help you get comfortable with both programming languages and server daemons provided as software collections.


First, add the right channel to your system

rhn-channel -u fatherlinux --add --channel=rhel-x86_64-server-6-rhscl-1-beta

To discover what packages are available, do a quick list, and grep for rhscl.

yum list available | grep rhscl
mariadb55.x86_64                      1-6.el6               rhel-x86_64-server-6-rhscl-1-beta
mariadb55-mariadb.x86_64              5.5.30-9.el6          rhel-x86_64-server-6-rhscl-1-beta
mariadb55-mariadb-bench.x86_64        5.5.30-9.el6          rhel-x86_64-server-6-rhscl-1-beta
mariadb55-mariadb-devel.x86_64        5.5.30-9.el6          rhel-x86_64-server-6-rhscl-1-beta
mariadb55-mariadb-libs.x86_64         5.5.30-9.el6          rhel-x86_64-server-6-rhscl-1-beta
mariadb55-mariadb-server.x86_64       5.5.30-9.el6          rhel-x86_64-server-6-rhscl-1-beta
mariadb55-mariadb-test.x86_64         5.5.30-9.el6          rhel-x86_64-server-6-rhscl-1-beta

Now, let’s install a few interesting packages

Continue reading “Software Collections Quickstart”


Drupal 7, PHP 5.4 and MySQL via Software Collections

In order to test out the new Red Hat Software Collections (RHSCL, announcement) version of PHP 5.4, I decided to build out a Drupal 7 install using the php54 collection and the mysql55 collection.

Overall, the activity was pretty much like a normal Drupal install. However, to use software collections you have to do a few things differently. Also, if you haven’t used a software collection for a “service” (e.g. MySQL) before, the service setup is also a little different than the native versions.

First and foremost, add the channels for RHSCL either via subscription manager or rhn. The name of the channel (for the beta) is rhel-server-rhscl-6-beta-rpms. After that, you need to install the software collections. So, something like:

#yum install php54 mysql55

You could also just install all the dependencies in the same line, but I wanted to pull them out to be able to comment on them a little bit more. I also tend to install some of the semi-optional components because I think Drupal works better that way.

First off, the easiest thing to install, which is also not really related to software collections, is gd (not called “GIF Draw” 🙂 ). Very simple, just install gd from the normal RHEL repositories.

#yum install gd

Next, we need the “driver” libraries for php to various other things. All the ones we need are included in the “php54 Software Collection” but are not installed by the simple install of the php54 package as they are not required for basic php. php54-php-gd is the connection from php to the gd library. php54-php-mbstring is a library for unicode, technically not a “driver” but an optional library. Finally, we need to connect to mysql so we install php54-php-mysqlnd.

#yum install php54-php-gd php54-php-mbstring php54-php-mysqlnd

Last but not least, we need to install the php “driver” for httpd. Now, I call this one out

Continue reading “Drupal 7, PHP 5.4 and MySQL via Software Collections”


PHP 5.4 on RHEL-6 using RHSCL

Official announcement : Red Hat Software Collections 1.0 Beta Now Available

More information on Software Collections

Stability addicts can keep quiet, PHP 5.3.3 is still the standard version provided with RHEL-6.

We’ll soon have an official and supported way to install PHP version 5.4, beside the system version, without any effect on installed components. The announcement tells us the life cycle will be 3 years.

Warning:  it’s a beta version, published for evaluation purposes.


Activation of the distribution channel (requires a valid subscription) from the RHN web interface or from command line:

Continue reading “PHP 5.4 on RHEL-6 using RHSCL”


Managing OpenStack with The Foreman

OpenStack is picking up a lot of steam these days, but getting it installed can be a hassle. Lots of puppet-based installers have popped up to automate this arduous task. Using Foreman, however, administrators can not only configure and install OpenStack using puppet, but provision & add new compute nodes at their fancy.

The Foreman is a Ruby on Rails application that does configuration management with puppet and provisioning. We’ll use both of these features to make using & administering OpenStack easier. Our installer leverages PackStack, which includes great puppet modules for setting up OpenStack. Combining these to setup and manage OpenStack Grizzly is a breeze!


  1. At least three machines running RHEL 6.4 with an active subscription to RHEL OpenStack Platform or Red Hat Cloud Infrastructure.. We recommend your OpenStack Compute & Controller nodes run on bare metal.
  2. Each machine needs to have a resolvable FQDN
  3. Each machine needs to be subscribed to a proper RHEL subscription
  4. The Foreman server should have its firewall configured to allow inbound network traffic on TCP ports 80, 443 and 8140 for Foreman and Puppet to function correctly
  5. The host running Foreman may be running selinux in Enforcing mode, but you must first install the ruby193-foreman-selinux package. Both the OpenStack controller and compute nodes can also run in enforcing mode if you install the openstack-selinux package. You must also manually set a boolean on the controller node: setsebool -P httpd_can_network_connect on

Continue reading “Managing OpenStack with The Foreman”


From upstream OpenJDK to RPMs on your machine

Over the past few years, I have been asked on and off as to what the process is for the RPMs that get into Red Hat Enterprise Linux and Fedora repositories. Over those years, the answer has evolved as we attempt to better the process. As it stands right now, there is a difference between how OpenJDK6, OpenJDK7 and OpenJDK8 (preview in Fedora 19) end up into RPMs. This post will shed some light into what those processes are.

This was the first (well, technically second, if you count the brief period when IcedTea7 was in Fedora before OpenJDK6) OpenJDK based JDK that was introduced in Fedora and RHEL.

OpenJDK6 has been EOLd by Oracle as of February 2013, and Red Hat has taken over maintainer-ship since. Since the goal of Fedora is to have the latest and greatest, we allowed OpenJDK6 in Fedora to EOL after Fedora 16 in favour of OpenJDK7. Enterprises however have much longer cycles and we continue to ship and support OpenJDK6 in RHEL-5 and RHEL-6 today.

OpenJDK6 in Fedora and RHEL has always been provided via a project named IcedTea. IcedTea was started by Red Hat to address build and binary plug issues that were in the initial version of OpenJDK. The purpose of IcedTea was to provide build scaffolding that made it easy to build OpenJDK, to provide open-source replacements for binary plugs, and to provide fixes that couldn’t otherwise make it into upstream OpenJDK.

The process for shipping new OpenJDK6 releases in Fedora and RHEL hasn’t really changed over the years and it is as follows:

Continue reading “From upstream OpenJDK to RPMs on your machine”