- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I've put some openmp directives on a do loop in fortran. Inside this do loop I call other subroutines. But when I run parallelel inspector to find data races it is giving a lot of data races on the local variables of the subroutines I call inside my do loop. I was suspecting that these were local to each thead because that are created in the thread local stack. But if this is correct than parallel inspecting is giving a lot of false positives and becomes useless because of the high number of these data race reports. Or is parallel inspector correct and this the normal behaviour for fortran code?
I've put some openmp directives on a do loop in fortran. Inside this do loop I call other subroutines. But when I run parallelel inspector to find data races it is giving a lot of data races on the local variables of the subroutines I call inside my do loop. I was suspecting that these were local to each thead because that are created in the thread local stack. But if this is correct than parallel inspecting is giving a lot of false positives and becomes useless because of the high number of these data race reports. Or is parallel inspector correct and this the normal behaviour for fortran code?
Link Copied
8 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi All,
I found the solution to my problem. In fortran local variable are static by default but by adding the /automatic compiler flag these local variables are allocated on the stack by default. This solves a lot of race conditions but I still have quite some false positive in my opinion. I illustrated this below
allocate variable !allocation site
!$omp parallal do
read shared variable !read
!$omp end parallel do
write shared variable !date race. but why????
I found the solution to my problem. In fortran local variable are static by default but by adding the /automatic compiler flag these local variables are allocated on the stack by default. This solves a lot of race conditions but I still have quite some false positive in my opinion. I illustrated this below
allocate variable !allocation site
!$omp parallal do
read shared variable !read
!$omp end parallel do
write shared variable !date race. but why????
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi:
In order to better address your question, can you tell us which version of the Intel Fortran compiler you are using and whether or not you are statcally linking the OpenMP runtime library?
In order to better address your question, can you tell us which version of the Intel Fortran compiler you are using and whether or not you are statcally linking the OpenMP runtime library?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is the paarallel do inside a parallel region?
This can occure if you have nested parallel regions.
(nested enabled)
!$omp parallel sections
call foo
!$omp section
call fee
!$omp end parallel sections
-------------
subroutine foo
...
!$omp parallel do
read shared variable xx in module yy or in common
!$omp end parallel do
write shared variable xx
...
end subroutine foo
------------------------
subroutine fee
...
!$omp parallel do
read shared variable xx in module yy or in common
!$omp end parallel do
write shared variable xx
...
end subroutine fee
The two writes to same shared xx could occure by two threads
Jim Dempsey
This can occure if you have nested parallel regions.
(nested enabled)
!$omp parallel sections
call foo
!$omp section
call fee
!$omp end parallel sections
-------------
subroutine foo
...
!$omp parallel do
read shared variable xx in module yy or in common
!$omp end parallel do
write shared variable xx
...
end subroutine foo
------------------------
subroutine fee
...
!$omp parallel do
read shared variable xx in module yy or in common
!$omp end parallel do
write shared variable xx
...
end subroutine fee
The two writes to same shared xx could occure by two threads
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm using intel fortran compiler version 11.0.072 and using staticaly linked libraries for openmp.
I do not have nested parrallel in my code and it is also not enabled (by default it is disable if I'm correct). In fact I only have one parallel region in my code at the moment.
I do not have nested parrallel in my code and it is also not enabled (by default it is disable if I'm correct). In fact I only have one parallel region in my code at the moment.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Following the copiler option guidelines discribed in http://software.intel.com/en-us/articles/compiler-settings-for-threading-error-analysis-in-intel-parrallel-inspector/ I could remove all the false positive mentioned above. Only one data race reported now in on a local variable (CHARACTER*5) in a fortran function. The /automatic does not seem to work in this case.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That's the problem! We currently don't support statically linking the OpenMP libraries and it will cause many false positives!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Indeed, This was also guidelines I mentioned in my previous post. BUt I still have one strange data race reported on a local CHARACTER(*) variable.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please submit a sample app that demonstrates the problem. If you can create a sample project and zip it up and attach it to this thread, that would allow us to investigate the reported behavior.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page