Interesting OpenMP TASK behavior

[jansson]

Hi,

I found a interesting behavior in my program and look for ideas to go forward fixing it.
This design do not work for me.

--
LOOP through linked list
!$OMP TASK default(none) ...
..
lots of code
..
!$OMP END TASK
END LOOP through linked list
!$OMP TASKWAIT
--


But below code does work.
Only a critical section with "CALL SleepQQ(1)" is added at the end of the TASK construct.

--
LOOP through linked list
!$OMP TASK default(none) ...
..
lots of code
..
!$OMP CRITICAL(NAME)
CALL SleepQQ(1)
!$OMP END CRITICAL(NAME)
!$OMP END TASK
END LOOP through linked list
!$OMP TASKWAIT
--

Further:
Without the critical section it does not work.
"CALL SleepQQ(0)" do not make program work.
A 1.1 ms buzzy wait loop does NOT work instead of SleepQQ(1)...
!$OMP FLUSH do not work.


All ides for cause and/or fix are welcome!

Best Regards,
Magnus

[Arjen_Markus]

From the description you gave it is pretty difficult to judge why
it does not work.Can you post a complete program that exhibits the
same non-satisfying behaviour?

Regards,

Arjen

[jansson]

It will probably not be possible to post a complete program.
I did not yet try to reproduce it in a postable code, its a large and old code I try to parallelize.

So I would be happy for other more general ideas finding race's. :)
Since any Critical section, where more than a few ms is spent, _seems_ to fix the problem it is hard to locate by making parts of the TASK construct at a time a critical section, I tried for a while, until I found this out. :)

Just noticed that it depends hevily on the OMP_NUM_THREADS variable, =4 works more than 95% and =8 fail about 50% of the times on my Core i5 (4 real cores OR 8 SMT cores)

Regards,
Magnus

[Arjen_Markus]

I am not sure, but data races may be analysed with one of Intel's additional tools. I have not used any
of them yet, so I can not give you much advise here.

In general data races are very difficult to spot. You have to examine the code very carefully and
even then it is not a trivial task at all. Writing things out usually destroys therace condition ...

Regards,

Arjen

[jimdempseyatthecove]

Magnus,

Takeyour task code block (the codeinside the !$OMP TASK/!$OMP END TASK) keep the TASK/ END TASKstatementsoutside of this subroutine.

subroutine CheckItOut(necessary args here)
...
lots of code
...
end subroutine CheckItOut

copy it to a subroutine, thus requiring you to explicitly state the variables passed across the parallel region barrier. This may help you by exposing an issue relating to shared/private. Once you discover the cause of the problem (and fix it) you can then decide if you want to place the code back in line.

Jim Dempsey

[jansson]

Thank you for the idea Jim.
I thought that default(none) could help in a similar way as making a explicit subroutine out of the task code block.
But maybe not, and it also might make it possible to acctualy see the values of all variables during Debugging. Holding me back was the number of arguments. Thanks for pushing me. :)
I will post again with my findings.

Regards,
Magnus

[jimdempseyatthecove]

The object lesson is to find the latent bug.
Use INTENT(IN) and INTENT(IN OUT) accordingly too