OpenMP private variable initialization

MARGUINAUD Philippe philippe.marguinaud@meteo.fr
Thu Mar 28 12:39:00 GMT 2013


Thank you for your remarks.

But I would nevertheless have expected the default initialization to
occur; when YA is declared

TYPE (TA) :: YA

it is not yet initialized (I have not assigned a value to it), but those
of its members which have a default value have been initialised.

But that is the way it is and I have to live with it.

Regards,

Philippe


On 28/03/2013 11:45, Rimvydas J wrote:
> On Thu, Mar 28, 2013 at 11:47 AM, Tobias Burnus <burnus@net-b.de> wrote:
> 
>> MARGUINAUD Philippe wrote:
>>
>>> I have a problem with the initialization of a private variable in an
>>> OpenMP loop. I do not know whether this is really a bug, but I would
>>> have expected a different behaviour.
>>>
>>> TYPE TA
>>>    INTEGER :: ILMESS = 1024
>>> END TYPE
>>>
>>> TYPE (TA) :: YA
>>>
>>>
>>> !$OMP PARALLEL PRIVATE (YA)
>>>     PRINT *, YA%ILMESS
>>> !$OMP END PARALLEL
>>>
>>
>> The OpenMP 3.1 specification states in "2.9.3.3 private clause" (in the
>> "Fortran" block, not the last sentence):
>>
>> "A new list item of the same type is allocated once for each implicit task
>> in the parallel region, or for each task generated by a task construct, if
>> the construct references the list item in any statement. The initial value
>> of the new list item is undefined."
>>
>> See http://www.openmp.org/mp-**documents/OpenMP3.1.pdf<http://www.openmp.org/mp-documents/OpenMP3.1.pdf>page 96 (= 104 page in the PDF)
>>
>>
>> The "firstprivate" clause, mentioned by Arjen, states (2.9.3.4, page 98
>> (p.106)):
>>
>> "The firstprivate clause declares one or more list items to be private to
>> a task, and initializes each of them with the value that the corresponding
>> original item has when the construct is encountered."
>>
>> Tobias
>>
> 
> Firstprivate directive helps for this specific case, but using this for
> complicated structures in actual code is almost undebuggable and very slow
> (structures usually tend to become overbloated). If there is a possibility
> to track read before write in OMP region, it is very efficient to
> externalize part of structure and/or [re]init specific parts it in OMP
> region.
> 
> Rimvydas.
> 



More information about the Fortran mailing list