[Omp] A question about threadprivate

[Marina Kraeva]

Dieter,

Yes, this behavior is clearly specified by API.

Marina.

Dieter an Mey wrote:

> The interesting point here is not related to threadprivate, but to the 
> way omp_get_thread_num() works with nesting.
> 
> Look at that:
> 
> source:
> 
> program main
> use omp_lib
>   print *, "case 1"
>     call omp_set_nested(.true.)
> !$omp parallel num_threads(2)
> !$omp parallel num_threads(1)
>                print *, omp_get_thread_num()
> !$omp end parallel
> !$omp end parallel
> 
>   print *, "case 2"
>     call omp_set_nested(.false.)
> !$omp parallel num_threads(2)
> !$omp parallel num_threads(1)
>                print *, omp_get_thread_num()
> !$omp end parallel
> !$omp end parallel
> 
>   print *, "case 3"
> !$omp parallel num_threads(2)
>                print *, omp_get_thread_num()
> !$omp end parallel
> 
> end program
> 
> 
> output:
>  case 1
>  0
>  0
>  case 2
>  0
>  0
>  case 3
>  0
>  1
> 
> regards,
> Dieter
> 
> Marina Kraeva schrieb:
> 
>> Larry,
>>
>> As I understood, Dieter suggested that the inner region modifying 'i' 
>> IS relevant, because the master threads of the inner regions will be 
>> modifying the parent copies of 'i', so after the nested parallel 
>> region all four copies of 'i' will have value '-0'.
>>
>> Anyway, I emailed a request to feedback at openmp.org asking to specify 
>> the behavior in various situations, including these two examples.
>>
>> Thanks again for your input!
>>
>> Marina.
>>
>>
>> Meadows, Lawrence F wrote:
>>
>>> Now that I re-read the second example, I agree with Dieter that
>>> the result is well-defined by the 2.0 standard:
>>>
>>>
>>>>>> int i,array(0:3)
>>>>>> threadprivate(i)
>>>>>> !$omp parallel num_threads(4)
>>>>>>    i=omp_get_thread_num()
>>>>>>    !$omp parallel num_threads(2)
>>>>>>                i=-omp_get_thread_num()
>>>>>>    !$omp end parallel
>>>>>> !$omp end parallel
>>>>>>
>>>>>> !$omp parallel num_threads(4) shared(array)
>>>>>>    array(omp_get_thread_num())=i
>>>>>> !$omp end parallel
>>>>>>
>>>
>>>
>>> The two outer parallel regions are consecutive, have the
>>> same number of threads, dyn-var is false, and nthreads-var
>>> hasn't changed. The inner region modifying 'i' is not
>>> relevant here, it is a different 'i'.
>>>
>>> So I believe that the value of 'i' for the threads in the second
>>> out parallel region is retained in both examples, and that this
>>> behavior is clearly specified by the standard.
>>>
>>>
>>
>