OpenMP with FORTRAN 'DO WHILE' loop?

OpenMP with FORTRAN 'DO WHILE' loop?


I know what document says about using OMP with FORTRAN 'DO WHILE' loop: do not ever use !$OPM PARALLEL DO.

So my question is not about using "!$OPM PARALLEL DO" with DO WHILE loop.

Say, I have a real situation where I can only use 'DO WHILE' loop, and a conversion to normal DO loop is not even possible, can I still use


DO WHILE (.logical expr.)


some code in the loop....




Anything wrong with this? pitfall potentially?

How about OMP sections and section? Any examples?

Any pointer will help.

5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

You need !$OMP SINGLE right after the start of parallel code, otherwise the tasks will get duplicated by all threads.

You need some ordinary version of omp syntax which will permit the run-time to partition the loop into threads, but you imply this "is not even possible."  For example, you could make an ordinary counted loop:

iter_set_by = nmax

logical_var = .true.

!$omp parallel do schedule(runtime) shared(logical_var, iter_set_by)

do i=1, nmax

   if(logical_var .or. i < iter_set_by)then



          logical_var = .false.

          iter_set_by = i




Once logical_var goes false, the iteration count for each chunk can be exhausted doing nothing, but you have to give each thread some work which doesn't depend on the others before anybody has set the exit condition, otherwise you have no useful parallelism.

You would also want to make logical_var volatile (to assure it is read on each test). Also consider using exit to the (of the) matching scope of the current do (OpenMP ought to permit slice termination by exit to matching END DO). Caution, should your do loop have a barrier, then you must not exit the loop. Use if(logical_var) as TimP shows, but place barrier outside this  then block (i.e. assure all threads reach barrier). N.B. TimP had "if(logical_expr)", I think he meant  "if(logical_var)". Also, do not use exit from within a critical section (as this would bypass the end critical section).

The TASK format may be a good alternative.

Jim Dempsey

I'm sorry for the incomplete editing of my suggestion.

As Jim says, making the shared control variables volatile (or using a critical) would assure more immediate recognition of a change, but still you would likely perform some extra loop iterations compared with the pure serial case, so you must consider whether that is valid.

Leave a Comment

Please sign in to add a comment. Not a member? Join today