Avoiding race conditions in omp

General OpenMP discussion

Avoiding race conditions in omp

Postby überfuzz » Thu Feb 13, 2014 6:06 pm

I just moved from pthreads to omp and have some qeustions regarding locks. Is there a locking feature that can lock entries or indices in arrays? Example:
Code: Select all
for(loop over assigned part of shared array: i)
   if(some conndition)
      put a lock on array[i]

//loop to unlock indices
überfuzz
 
Posts: 4
Joined: Thu Feb 13, 2014 1:10 pm

Re: Avoiding race conditions in omp

Postby MarkB » Fri Feb 14, 2014 3:23 am

überfuzz wrote:Is there a locking feature that can lock entries or indices in arrays?


If you are doing simple read/write/update/capture operations on the array, and the array is of scalar type, you can use atomic constructs. However, this comes with no guarantee of allowing concurrent accesses to different memory locations: a compliant implementation can use a global lock to protect all such atomic accesses.

It is possible to declare an array of locks the same size as the array to be protected, and, say, acquire lock[i] to protect array[i].
If the array is large and clashes not too frequent, it may make more sense to declare a smaller array of locks and use each lock to protect a
range of indices in the array.

Hope that helps,
Mark.
MarkB
 
Posts: 452
Joined: Thu Jan 08, 2009 10:12 am
Location: EPCC, University of Edinburgh

Re: Avoiding race conditions in omp

Postby ftinetti » Fri Feb 14, 2014 6:31 am

Hi,

Taking into account that you are moving from pthreads where locks are almost the only way of synchronization, I think you can also take a look at the "Master and Synchronization Constructs" of OpenMP, at least to have a general idea of other synchronization mechanisms available in OpenMP.

HTH,

Fernando.
ftinetti
 
Posts: 582
Joined: Wed Feb 10, 2010 2:44 pm

Re: Avoiding race conditions in omp

Postby überfuzz » Fri Feb 14, 2014 6:53 am

Oki! Thanks a lot for your time Mark!

So I'm locking places in the memory with omp atomic. If I have integers as entries in the array I cast a lock with the size of an integer? The set of locks you mentioned how would I implement that?
Code: Select all
for(loop:i)
   if(array[i] meats some condition)
      #pragma omp atomic
      array[i];

      //Do something brilliant with array[i]

   unlock array[indices that were locked]


When I look in the documentation I can't see this that atomic has this kind of feature. The thing is, I try to manipulate the global array trivially. If a conflict is detected the trivial manipulation is stopped and the array is handled in a thread safe way.
Code: Select all
memory |----|----|****|----|----|****|----| if conflict is detected

                  lock           lock                                 (number of lock << length of array.)
memory |----|----|data|----|----|data|----| manipulate with locks

memory |----|----|data|----|----|data|----| access is free again.


Is it possible to assign multiple locks in this manner by using omp atomic? If not is there an other way?
überfuzz
 
Posts: 4
Joined: Thu Feb 13, 2014 1:10 pm

Re: Avoiding race conditions in omp

Postby überfuzz » Fri Feb 14, 2014 7:04 am

Fernando - Well there are some neat locking features in pthreads. At the moment I feel like it's much easier to control fine grained stuff I pthread. But enough about pthreads. :-)
überfuzz
 
Posts: 4
Joined: Thu Feb 13, 2014 1:10 pm

Re: Avoiding race conditions in omp

Postby MarkB » Fri Feb 14, 2014 10:34 am

Hi there,

OpenMP does not have the concept of locked data, either permanent or temporary. Atomics work by protecting the access only in the associated statement (or possibly statement pair, in the case of captures).

OpenMP locks are not directly associated with data or memory locations - like pthread mutexes, which they resemble closely, it's up to the programmer to make the association logically.

You might want to consider a solution like this:

Code: Select all
for(loop:i)
   if(array[i] meats some condition)

     lockid = i/num_indices_per_lock;

    omp_set_lock(locks[lockid]);
      //Do something brilliant with array[i]
    omp_unset_lock(locks[lockid]);



Note that to completely avoid race conditions, you may need to set the lock before testing the condition:

Code: Select all
for(loop:i)
   lockid = i/num_indices_per_lock;
   omp_set_lock(locks[lockid]);
   if(array[i] meats some condition)
         //Do something brilliant with array[i]
   omp_unset_lock(locks[lockid]);

MarkB
 
Posts: 452
Joined: Thu Jan 08, 2009 10:12 am
Location: EPCC, University of Edinburgh

Re: Avoiding race conditions in omp

Postby überfuzz » Fri Feb 14, 2014 3:33 pm

OK, thanks a lot!

I don't quite get what you mean... I found some documentation over the 'lock' you mentioned, thanks: http://msdn.microsoft.com/en-us/library/8xybk13s.aspx
Not a deal-breaker, but why do I have to initiate the lock outside my loops, and outside the parallel region?

You're suggesting that I should set up an array of these locks: locks[], or? How would I write this in C?

Code: Select all
for(int i = 0; i<n; ++i){
   if(array[i] == some conndition)
      omp_set_lock(my_lock_array[i])
}


Sry If I mess it all up. I'm still like Bamby on is when it comes to omp. :?
überfuzz
 
Posts: 4
Joined: Thu Feb 13, 2014 1:10 pm

Re: Avoiding race conditions in omp

Postby MarkB » Mon Feb 17, 2014 7:49 am

überfuzz wrote:You're suggesting that I should set up an array of these locks: locks[], or? How would I write this in C?


Something like this:

Code: Select all
#include <omp.h>

omp_lock_t  *my_lock_array;

my_lock_array = (omp_lock_t *) malloc(nlocks*sizeof(omp_lock_t));

for (i=0; i<nlocks; i++) {
        omp_init_lock(&my_lock_array[i]);
}


You could allocate and initialise the locks inside the parallel region, so long as you synchronise the threads to ensure that the locks are intialised before they are used. However if you are going to execute the parallel region more than once, it's more efficient to keep the lock array around rather than recreate it every time.
MarkB
 
Posts: 452
Joined: Thu Jan 08, 2009 10:12 am
Location: EPCC, University of Edinburgh


Return to Using OpenMP

Who is online

Users browsing this forum: Google [Bot] and 14 guests