Changes

===Creating and executing Threads===

Inside a declared OpenMp parallel region, if not specified via an environment variable OMP_NUM_THREADS or the library routine omp_get_thread_num() , OpenMp will automatically decide how many threads are needed to execute parallel code.

An issue with this approach is that OpenMp is unaware how many threads a CPU can support. A result of this can be OpenMp creating 4 threads for a single core processor which may result in a degradation of performance.

}

C++ 11 Threads on the contrary always required to specify the number of threads required for a parallel region. If not specified by user input or hard-coding, the number of threads supported by a CPU can also be accurately via the std::thread::hardware_concurrency(); function.

OpenMp automatically decides what order threads will execute. C++ 11 Threads require the developer to specify in what order threads will execute. This is typically done within a for loop block. Threads are created by initializing the std::thread class and specifying a function or any other callable object within the constructor.

}

Serial Implementation

A future is an object that can retrieve a value from some provider object (also known as a promise) or function. Simply put in the case of multithreading, a future object will wait until its associated thread has completed and then store its return value.

To retrieve or construct a future object, these functions may be used.

However, a future object can only be used if it is in a valid state. Default future objects constructed from the std::async template function are not valid and must be assigned a valid state during execution.

A std::future references a shared state that cannot be shared to other asynchronous return objects. If multiple threads need to wait for the same shared state, std::shared_future class template should be used.

Openmp unfortunately does not support asynchronous multi-threading as is designed for designed for parallelism, not concurrency.

Can one safely use C++11 multi-threading as well as OpenMP in one and the same program but without

interleaving them (i.e. no OpenMP statement in any code passed to C++11 concurrent features and no

C++11 concurrency in threads spawned by OpenMP)?

On some platforms efficient implementation could only be achieved if the OpenMP run-time is the

also proponents of other execution models (e.g. Intel with Cilk and TBB, GCC with C++11, etc.)

and x86 is usually considered an "experimental" platform (other vendors are usually much more conservative).