Sharing a private variable with tasks

General OpenMP discussion

Sharing a private variable with tasks

Postby buttari » Fri Dec 20, 2013 7:31 am

Hello,
consider the case where a single thread (say, the master) has a private vector x and submits a number of tasks which update different coefficients of x. Here is a simple (fortran) code that does this

Code: Select all
program main
  implicit none

  integer, allocatable :: x(:)
  integer              :: m, j

  m = 10
 
  !$omp parallel private(x)
  !$omp master
  allocate(x(m))
  do j=1, m
     !$omp task firstprivate(j) shared(x)
     x(j) = j
     !$omp end task
  end do
  !$omp taskwait
  deallocate(x)
  !$omp end master
  !$omp end parallel

  stop
 
end program main


I would like to know whether this code is OpenMP compliant and/or correct.
My understanding is that the shared clause in the task construct is such that within the task the actual x array is the one that was allocated by the master, regardless of the thread executing the task. Is this correct?

This code does not work with intel ifort. The compiler complains about x not being allocated (if I turn on the compiler bounds check whistles). If I remove the deallocate statement then the code works ok but because of the taskwait, the deallocation should not be executed before all the tasks are done and thus this behavior seems totally strange to me. Also, the code works fine if I make x a pointer instead of an allocatable.

The code works fine with gfortran.

Is this an ifort bug?

Kind regards,
alfredo
buttari
 
Posts: 11
Joined: Wed Oct 29, 2008 10:41 am

Re: Sharing a private variable with tasks

Postby ftinetti » Sat Dec 21, 2013 8:07 am

Hi Alfredo,

My understanding is that the shared clause in the task construct is such that within the task the actual x array is the one that was allocated by the master, regardless of the thread executing the task. Is this correct?

I don't think so, because the 4.0 Spec., section 2.11.1, page 115, defines:
A thread that encounters a task scheduling point within the task region may
temporarily suspend the task region. By default, a task is tied and its suspended task
region can only be resumed by the thread that started its execution. If the untied
clause is present on a task construct, any thread in the team can resume the task
region after a suspension.

so I think every task created with
Code: Select all
!$omp task firstprivate(j) shared(x)

is a tied task and should be executed only by "the thread that started its execution. "... or I've lost something... I'm far from being an expert in tasking, though, so I would like some explanation from an expert.
HTH,

Fernando.
ftinetti
 
Posts: 567
Joined: Wed Feb 10, 2010 2:44 pm

Re: Sharing a private variable with tasks

Postby buttari » Sat Dec 21, 2013 8:47 am

Fernando,
thanks for taking the time to reply. I don't really see the connection between the part of the standard you quoted and my problem. My concern here is the status and content of the x array seen within the task. I don't think this has anything to do with a task being tied or untied. Unless I miss something...

regards,
alfredo
buttari
 
Posts: 11
Joined: Wed Oct 29, 2008 10:41 am

Re: Sharing a private variable with tasks

Postby ftinetti » Sat Dec 21, 2013 10:31 am

I don't really see the connection between the part of the standard you quoted and my problem. My concern here is the status and content of the x array seen within the task. I don't think this has anything to do with a task being tied or untied. Unless I miss something...


Hmm... I assumed somethings I should have explained. I was specifically referring to the part of your post I included in my reply, and I'll include it again, since you say
(in short)
"...regardless of the thread executing the task."

"My" understanding is: it is not possible, or applicable (what you posted) beyond the only one thread to which the task is tied, since a tied task
...can only be resumed by the thread that started its execution.

in terms of the Spec.

You are right I was not referring specifically to the "x array", but I think it's related, since you expect some behavior on the "x array" based on the tasks and the way you understand they are executed, which I think is not the one defined by the Spec. Of course, all of this is about the Spec., I didn't try any thing at the compilers (maybe they are buggy too, maybe not...).

I hope I explained a little bit better this time. Anyway, remember I'm not "the" authorized word.

HTH,

Fernando.
ftinetti
 
Posts: 567
Joined: Wed Feb 10, 2010 2:44 pm

Re: Sharing a private variable with tasks

Postby buttari » Thu Dec 26, 2013 2:34 am

Fernando,
forgive me but I still do not see how this is related to my problem. I am sure that all the tasks are created by the same thread (the master) so, in some sense, I am sure of what x is at the moment when the tasks are created. I just want it to be the same also when the tasks are executed. I am not making any assumption on the threads who execute the tasks. What I want to achieve is simply to pass x from the master to whatever thread executes the task.

There are other things that trouble me. If the standard says that this thing is not allowed/valid, then my code should never work but, instead, it works ok with gfortran and it woks with ifort in most cases (when x is a pointer or a simple variable) except when x is an allocatable. It also works in C/C++ if x is a pointer.

Moreover, take the fibonacci example on the OpenMP specs; variables i and j are implicitly private to the thread creating the tasks and they are declared as shared in the task construct in order to pass the result from the thread who executed the task to the thread who created the task. In some sense, this example is equivalent to my code above. The only major difference I can see is that x is an allocatable but the standard does not say anything about this case (unless I missed something).

Thanks for the help,
alfredo
buttari
 
Posts: 11
Joined: Wed Oct 29, 2008 10:41 am

Re: Sharing a private variable with tasks

Postby ftinetti » Thu Dec 26, 2013 6:21 am

Hi Alfredo,

Examples suggest you are right about un/tied tasks... or maybe I'm not understanding the spec. ... My "reasoning" is as follows:
Based on section 2.11.1, page 115:
A thread that encounters a task scheduling point within the task region may
temporarily suspend the task region. By default, a task is tied and its suspended task
region can only be resumed by the thread that started its execution. If the untied
clause is present on a task construct, any thread in the team can resume the task
region after a suspension.

I looked for the definition of a task scheduling point, which is in section 2.11.3, p. 118:
Task scheduling points are implied at the following locations:
• the point immediately following the generation of an explicit task
...

so I concluded that only the generating thread could complete/resume/execute the task, but following this "reasoning" most of the examples would not work as described...

I'll specifically check the examples and see if I can learn something about it...

Sorry for the "noisy answer",

Fernando.
ftinetti
 
Posts: 567
Joined: Wed Feb 10, 2010 2:44 pm

Re: Sharing a private variable with tasks

Postby buttari » Fri Dec 27, 2013 12:17 pm

ftinetti wrote:so I concluded that only the generating thread could complete/resume/execute the task, but following this "reasoning" most of the examples would not work as described...


Fernando,
this is not correct. Any thread can start the execution of a task no matter what other thread has created it (tasks would not make much sense otherwise). Once the execution of a task has started, it may be interrupted; now if an interrupted task is tied, it's execution can only be resumed/completed by the thread who started it. Therefore a tied task is not tied to the thread who created it but to the one who started its execution. I hope this clear up some of your doubts.

By the way, this is issue was cleared on the Intel Forums; it seems to be an ifort bug indeed:

http://software.intel.com/en-us/forums/ ... nt-1775559

Regards,
Alfredo
buttari
 
Posts: 11
Joined: Wed Oct 29, 2008 10:41 am


Return to Using OpenMP

Who is online

Users browsing this forum: Google [Bot] and 3 guests