Fortran - OpenMP: data scoping and modules

Author

OpenMP: data scoping and modules

joaquin.casanova@gmail.com

2007-02-27, 7:09 pm

I'm getting

by OpenMP behaviour for shared/private. I can't
find a definitive answer about the rules for shared-ness of variables
defined in modules. Let's say I have a program like this:

PROGRAM test

use omp_lib
use utils

implicit none

real::out,x

call sub

call omp_set_num_threads(4)

!$omp parallel private(out,x)
x = ...
out = func(x)
print*,x,out,omp_get_num_thread()
!$omp end parallel

END PROGRAM test

MODULE utils

use data
implicit none

contains

FUNCTION func(x) result(y)
...
private_data = x
...
END FUNCTION func

SUBROUTINE sub
...
shared_data = ...
...
END SUBROUTINE sub

END MODULE utils

MODULE data

implicit none

real::shared_data
real::private_data

!$omp threadprivate(private_data)

END MODULE data

My question is this: with the omp directives in this example, is
shared_data shared, and is private_data private? Thanks for your help.

Reinhold Bader

2007-02-28, 4:08 am

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Joaquin,

The short answer to your question: Yes.

However, in general it is recommended to keep the usage of global
variables to a minimum, since the "non-locality" in programming style
is error-prone. In your example, just assume that "sub" is called within
a threaded region. Then, at the very least, you need to put updates
to shared_data into a critical region. Even so, your algorithm may
not work as intended.

Regards

joaquin.casanova@gmail.com wrote:
> I'm getting

by OpenMP behaviour for shared/private. I can't
> find a definitive answer about the rules for shared-ness of variables
> defined in modules. Let's say I have a program like this:
>
> PROGRAM test
>
> use omp_lib
> use utils
>
> implicit none
>
> real::out,x
>
> call sub
>
> call omp_set_num_threads(4)
>
> !$omp parallel private(out,x)
> x = ...
> out = func(x)
> print*,x,out,omp_get_num_thread()
> !$omp end parallel
>
> END PROGRAM test
>
> MODULE utils
>
> use data
> implicit none
>
> contains
>
> FUNCTION func(x) result(y)
> ...
> private_data = x
> ...
> END FUNCTION func
>
> SUBROUTINE sub
> ...
> shared_data = ...
> ...
> END SUBROUTINE sub
>
> END MODULE utils
>
> MODULE data
>
> implicit none
>
> real::shared_data
> real::private_data
>
> !$omp threadprivate(private_data)
>
> END MODULE data
>
> My question is this: with the omp directives in this example, is
> shared_data shared, and is private_data private? Thanks for your help.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFF5TXUFVLhKuD7VgsRAoKdAJ48qwHkkAQR
A1BSjsfzS3NksOWyDgCfV2Gs
zhYeo8wrLiENn/XPUUYVPPw=
=pSZF
-----END PGP SIGNATURE-----

joaquin.casanova@gmail.com

2007-02-28, 7:07 pm

> Hello Joaquin,
>
> The short answer to your question: Yes.
>
> However, in general it is recommended to keep the usage of global
> variables to a minimum, since the "non-locality" in programming style
> is error-prone. In your example, just assume that "sub" is called within
> a threaded region. Then, at the very least, you need to put updates
> to shared_data into a critical region. Even so, your algorithm may
> not work as intended.
>
> Regards
>

OK, thanks. So in this case, if i took private_data out of module data
and instead kept it only as an argument to func, that would be better
because I'd have fewer globally declared variables, but it would still
be private, because it's declared inside func?

Sponsored Links