Code Comments
Programming Forum and web based access to our favorite programming groups.I'm gettingby 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.
Post Follow-up to this message-----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 gettingby 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-----
Post Follow-up to this message> 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?
Post Follow-up to this messagePowered by vBulletin
Copyright 2000-2006 Jelsoft Enterprises Limited.