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

nchen.dev at mac.com nchen.dev at mac.com
Tue Feb 15 12:59:04 EST 2011


Hi

A patch has been made available for this data race at <http://wiki.cs.princeton.edu/index.php/PARSEC#Patches_and_Bugfixes>. Search for "Data race in blackscholes OpenMP version" by Paul Keir. It basically marks those variables as private. I had just applied the patch recently which is why the issue is still fresh in my mind.

Hope this helps.

--
Nick Chen
University of Illinois at Urbana-Champaign

On Feb 14, 2011, at 6:37 AM, Jim Dempsey wrote:

> You are right. The variable price should have been private, or eliminated:
> 
>            prices[i] = BlkSchlsEqEuroNoDiv( sptprice[i], strike[i],
>                                         rate[i], volatility[i], otime[i],
>                                         otype[i], 0);
> 
> Jim Dempsey
> -----Original Message-----
> From: parsec-users-bounces at lists.cs.princeton.edu
> [mailto:parsec-users-bounces at lists.cs.princeton.edu] On Behalf Of Amittai
> Aviram
> Sent: Saturday, February 12, 2011 11:48 PM
> To: parsec-users at lists.cs.princeton.edu
> Subject: [parsec-users] Possible bug in blackscholes (OpenMP)?
> 
> Hi!  
> 
> 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 2.9.1.1.) 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
> http://www.amittai.com
> 
> _______________________________________________
> parsec-users mailing list
> parsec-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/parsec-users
> 
> _______________________________________________
> parsec-users mailing list
> parsec-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/parsec-users



More information about the parsec-users mailing list