Page MenuHomePhabricator

[OMPT] Fix inaccuracies in worksharing tests

Authored by Hahnfeld on Nov 9 2017, 10:59 AM.



These tests were failing rarely on my MacBook when there was some
activity in the background. Read: one of a thousand executions?

  • sections.c missed the sorting based on thread ids. This worked as long as the master thread finished its section before the worker thread started the second one but failed if the master thread was put to sleep by the OS.
  • The checks in single.c assumed that the master thread executes the single region which works most of the time because it is usually faster than the newly spawned worker thread.

Diff Detail


Event Timeline

Hahnfeld created this revision.Nov 9 2017, 10:59 AM

Sections seems reasonable, for the single I would suggest to use the conditional.

12 ↗(On Diff #122275)

In other tests we use something like:

int cond=0;
#pragma omp parallel num_threads(2)
  #pragma omp single
Hahnfeld added inline comments.Nov 9 2017, 1:24 PM
12 ↗(On Diff #122275)

I only see this for test cases involving tasks where we need to enforce a certain scheduling order. This is not needed here because we only want to test that one thread enters the single and the other one does not. We don't really care which one it is, do we?

protze.joachim added inline comments.Nov 10 2017, 8:42 AM
12 ↗(On Diff #122275)

Well, by enforcing the ordering we could predict which thread should throw which callback. With the DAG you only test, that the two threads throw different callbacks.

Probably print something (frame/address) in the single region and test that this was printed by the same thread as ompt_event_single_in_block_begin.

Hahnfeld updated this revision to Diff 122453.Nov 10 2017, 9:02 AM

Output line for thread that enters single region.

hbae accepted this revision.Nov 16 2017, 12:24 PM


This revision is now accepted and ready to land.Nov 16 2017, 12:24 PM
This revision was automatically updated to reflect the committed changes.