[parsec-users] Possible bug in blackscholes (OpenMP)?

Amittai Aviram amittai.aviram at yale.edu
Sun Feb 13 00:47:44 EST 2011


The blackscholes benchmark's main code file, blackscholes.c, has the following function definition, which I have simplified by using unifdef to expose only the code relevant to OpenMP:

int bs_thread(void *tid_ptr) {

    int i, j;
    fptype price;
    fptype priceDelta;

    for (j=0; j<NUM_RUNS; j++) {
#pragma omp parallel for
        for (i=0; i<numOptions; i++) {
            /* Calling main function to calculate option value based on         
             * Black & Sholes's equation.                                       
            price = BlkSchlsEqEuroNoDiv( sptprice[i], strike[i],
                                         rate[i], volatility[i], otime[i],
                                         otype[i], 0);

            prices[i] = price;

    return 0;

(I've also stripped out three variable assignments that should have been conditionally compiled for ENABLE_THREADS rather than ENABLE_OPENMP.)  The inner loop, within the OpenMP parallel-for block, assigns a value to the local variable price on each iteration.  When OpenMP splits this loop up into chunks to apportion to threads, each thread will be assigning to price.  But, since price is not declared _private_, its default attribute (by my reading of OpenMP 3.0 Specification subsection is _shared_.  Therefore, there is a data race between concurrent threads assigning to the shared variable price.

Is this a data race?  If it is and has already been noted, forgive me:  I couldn't figure out how to search the archives for this mailing list.  If it is and has never been noted, I would like to propose a bug fix on the parsec mailing list.

Thank you!

Amittai Aviram
PhD Student in Computer Science
Yale University
646 483 2639
amittai.aviram at yale.edu

More information about the parsec-users mailing list