CODEWITHSUNDEEP
c++multithreadingparallel-processingsynchronizationopenmp
Mobius88
Mobius88

Reputation: 111

Synchronization in OpenMP

I am trying to implement a parallel algorithm with OpenMP. In principle I should have many threads writing and reading different components of a shared vector in an ashyncronous way. There is a FOR loop in which the threads cycle and when a thread is in, let's say, row A of the loop it writes on a random component of the shared vector, while when it is in row B it reads a random component of the same shared vector. It may happen that a thread would try to read a component of the shared vector while this component is written by another thread. How to avoid inconsistency?

I read about locks and critical sections, but I think this is not the solution. For example, I can set a lock around row A in which the threads write in the shared vector, but does this prevent inconsistency if at the same time a thread in row B is trying to read that component?

Upvotes: 0

Views: 1613

Answers (1)

Hristo Iliev
Hristo Iliev

Reputation: 74365

If the vector modifications are very simple single-value assignment operations and are not actually function calls, what you need are probably atomic reads and writes. With atomic operations, a read from an array element that is simultaneously being written to will either return the new value or the previous value; it will never return some kind of a bit mash of the old and the new value. OpenMP provides the atomic construct for that purpose. On certain architectures, including x86, atomics are far more lightweight than critical sections.

With more complex modifications you have to use critical sections. Those could be either named or anonymous. The latter are created using

#pragma omp critical
code block

Anonymous critical sections all map to the same synchronisation object, no matter what the position of the construct in the source code, therefore it is possible for unrelated code sections to get synchronised with all possible ill effects, like performance degradation or even unexpected deadlocks. That's why it is advisable to always use named critical sections. For example, the following two code segments will not get synchronised:

// -- thread i --                  // -- thread j --
...                                ...
#pragma omp critical(foo)  <       #pragma omp critical(foo)
do_something();            <       do_something;
...                                ...
#pragma omp critical(bar)          #pragma omp critical(bar)  <
do_something_else();               do_something_else();       <
...                                ...

(the code currently being executing by each thread is marked with <)

Note that critical sections bind to all threads of the program, without regard to the team to which the threads belong. It means that even code that executes in different parallel regions (a situation that mainly arises when nested parallelism is used) gets synchronised.

Upvotes: 2

Related Questions