omp_get_max_threads in parallel region

[vondele]

I'm wondering if (omp_get_max_threads()<omp_get_num_threads()) can ever be true (I have an implementation that returns this) ? My feeling is that this is not the case, can that be confirmed by a verse from the standard ? The testcase:

SUBROUTINE TEST()
IMPLICIT NONE
INTEGER :: ithread,nthread,mthread
!$ INTEGER :: omp_get_thread_num, omp_get_max_threads, omp_get_num_threads

ithread=0
nthread=1
mthread=1

!$OMP PARALLEL PRIVATE(ithread,nthread,mthread)
!$ nthread=omp_get_max_threads()
!$ mthread=omp_get_num_threads()
!$ ithread=omp_get_thread_num()
!$OMP CRITICAL
write(6,*) ithread,nthread,mthread
!$OMP END CRITICAL
!$OMP END PARALLEL

END SUBROUTINE TEST

CALL TEST()

END

would print :

3 1 4
0 1 4
1 1 4
2 1 4

Thanks,

Joost

[ejd]

If you look at the OpenMP V2.5 spec, section 3.2.3 omp_get_max_threads states:

Summary
The omp_get_max_threads routine returns the value of the nthreads-var internal
control variable, which is used to determine the number of threads that would form the
new team, if an active parallel region without a num_threads clause were to be
encountered at that point in the program.
...
Effect
The following expresses a lower bound on the value of omp_get_max_threads: the
number of threads that would be used to form a team if an active parallel region
without a num_threads clause were to be encountered at that point in the program is
less than or equal to the value returned by omp_get_max_threads.

Your program is looking at the number of threads in the current region and the max threads number for the next region. So yes, it is possible to have omp_get_max_threads() < omp_get_num_threads(), because omp_get_num_threads() is returning the number of threads in the current parallel region and omp_get_max_threads() is returning the number of threads that would be in the next parallel region if a parallel construct were encountered where the call to omp_get_max_threads() was made.

The thing of interest to me, is that the implementation seems to also be considering the value of OMP_NESTED when returning the value of omp_get_max_threads. If you look in section 2.3 Internal Control Variables, it says that the nthreads-var value is what is returned when you call omp_get_max_threads() and that omp_set_num_threads() (or OMP_NUM_THREADS) is the only way to modify the value of nthreads-var. If this had been done by the implementation, then I would have expected the values returned by your two calls to be the same. However, if the implementation also takes into account whether nesting is allowed (or supported), then nthreads-var would be 1 as returned by your call.

[vondele]

The documentation says:

3.2 OMP_NESTED – Nested parallel regions
Description:
Enable or disable nested parallel regions, i.e., whether team members are allowed to create new teams. The value of this environment variable shall be TRUE or FALSE. If undefined, nested parallel regions are disabled by default.

so OMP_NESTED should be false for this run.

[ejd]

OMP_NESTED defaults to FALSE unless the user specifies otherwise (through an environment variable in your example) and the implementation supports nesting. The point was that, I don't believe you can find anything in the spec that says that the ICV nthreads-var depends on the value of the ICV nest-var. Therefore, the implementation you are using is doing something slightly different than other implementations might do. I would expect that many implementations might return 4 for the call to omp_get_max_threads() rather than 1. With nesting off, you would never get more than 1 thread in a nested parallel region, so technically the value returned is correct. However, as far as the spec is concerned, I believe a value of 4 is also correct.