Tool Chain Requirements

OpenMP support for RTEMS is available via the GCC provided libgomp. To enable the OpenMP support for GCC add the --enable-libgomp option to the GCC configure command line. There is libgomp support for RTEMS in the POSIX configuration of libgomp since GCC 4.9 (requires a Newlib snapshot after 2015-03-12). In GCC 6.1 or later (requires a Newlib snapshot after 2015-07-30 for <sys/lock.h> provided self-contained synchronization objects) there is a specialized libgomp configuration for RTEMS which offers a significantly better performance compared to the POSIX configuration of libgomp. In addition, application configurable thread pools for each scheduler instance are available in GCC 6.1 or later. Make sure that RTEMS is configured with the --enable-smp option.

Configuration

The run-time configuration of libgomp is done via environment variables documented in the ​libgomp manual. The environment variables are evaluated in a constructor function which executes in the context of the first initialization task before the actual initialization task function is called (just like a global C++ constructor). To set application specific values, a higher priority constructor function must be used to set up the environment variables.

#include <stdlib.h>

void __attribute__((__constructor__(1000))) config_libgomp(void)
{
    setenv("OMP_DISPLAY_ENV", "VERBOSE", 1);
    setenv("GOMP_SPINCOUNT", "30000", 1);
    setenv("GOMP_RTEMS_THREAD_POOLS", "1$2@SCHD", 1);
}

The environment variable GOMP_RTEMS_THREAD_POOLS is RTEMS-specific. It determines the thread pools for each scheduler instance. The format for GOMP_RTEMS_THREAD_POOLS is a list of optional <thread-pool-count>[$<priority>]@<scheduler-name> configurations separated by : where:

• <thread-pool-count> is the thread pool count for this scheduler instance.

• $<priority> is an optional priority for the worker threads of a thread pool according to pthread_setschedparam. In case a priority value is omitted, then a worker thread will inherit the priority of the OpenMP master thread that created it. The priority of the worker thread is not changed by libgomp after creation, even if a new OpenMP master thread using the worker has a different priority.

• @<scheduler-name> is the scheduler instance name according to the RTEMS application configuration.

In case no thread pool configuration is specified for a scheduler instance, then each OpenMP master thread of this scheduler instance will use its own dynamically allocated thread pool. To limit the worker thread count of the thread pools, each OpenMP master thread must call omp_set_num_threads.

Lets suppose we have three scheduler instances IO, WRK0, and WRK1 with GOMP_RTEMS_THREAD_POOLS set to "1@WRK0:3$4@WRK1". Then there are no thread pool restrictions for scheduler instance IO. In the scheduler instance WRK0 there is one thread pool available. Since no priority is specified for this scheduler instance, the worker thread inherits the priority of the OpenMP master thread that created it. In the scheduler instance WRK1 there are three thread pools available and their worker threads run at priority four.

Open Issues

• Atomic operations and OpenMP are not supported in GCC, see ​Bug 65467. Due to this a #include <rtems.h> is not possible in files compiled with -fopenmp if used by the C compiler (C++ works). Problem is solved in GCC 7.

• Earlier versions of libgomp used dynamic memory in the hot path. This was solved by ​GCC r225811.

• The libgomp uses the standard heap for dynamic memory. Since a gomp_free() function is missing it is hard to replace this with a dedicated heap.

OpenMP Validation

Originally the ​OpenMP 3.1 Validation Suite was selected to validate the OpenMP support. Due to some problems with this,the test suite results are currently not available. Tests that failed on RTEMS failed also on Linux. There were two related bug reports to GCC ​Bug 65385 and ​Bug 65386. The quality of the test suite itself turned out to be quite bad.