2

I'm watching this Introduction to OpenMP series of videos, and the presenter keeps repeating that "heap is shared, stack is private". It is also mentioned that data and text areas are shared. However he gives examples where stack variables of the parent thread are obviously shared and he keeps referring to those variables as being "on the heap". Here's an example:

https://youtu.be/dlrbD0mMMcQ?t=2m57s

He claims that variables index and count are "on the heap". Isn't index on the stack of the parent thread? Isn't count a static variable, and so part of the data area? In my own OMP programs, if I print the address of such variables they appear to be on the stack and data area, respectively. This is not the only place so far that he has referred to variables as "on the heap" that from what I can tell, are shared, but not on the heap. I just want to make sure I'm not missing something about the way OMP works.

Reading the specification, the clearest statement I could find of this for "implicit sharing" of stack variables outside the parallel region:

For constructs other than task generating constructs or target constructs, if no default clause is present, these variables reference the variables with the same names that exist in the enclosing context

OpenMP 4.5 Specification p.182

Spearman
  • 149
  • 6
  • `"heap is shared, stack is private"` refers to each individual thread's stack. Obviously the stack for the master thread (e.g. `main()`) can contain data that is shared among the threads. (personally, I don't see how you can expect to learn a technical subject by watching a video of some middle-aged graying guy wobbling back and forth on the screen `:)` – David C. Rankin Jan 07 '18 at 09:18
  • Here is a previous Question that relates to this [What resources are shared between threads?](https://stackoverflow.com/questions/1762418/what-resources-are-shared-between-threads) – David C. Rankin Jan 07 '18 at 09:23
  • I did read that already and am pretty clear on what threads share, although I tagged the question with C and Multithreading it is more of a question about how OpenMP works. I agree the videos may not be the best but they seem to be a decent introduction, except for this issue of calling any shared variable a "heap variable". He's so consistent about it that I thought it's possible that since the videos are a few years old, maybe an older version of OpenMP used to move shared variables to the heap or something. – Spearman Jan 07 '18 at 09:40
  • Yes, that is the weird part. You would think somebody who is putting out videos would be concise enough to use the correct verbiage -- but I have suffered through enough crappy professors in my years to know that isn't always the case. (be wary of internet videos -- many times they are not the best) Whether it is openMP pthreads, etc. the concept doesn't change. Each thread has it's own local call stack and variables local to the thread are private. Just about everything else can be shared. – David C. Rankin Jan 07 '18 at 09:44
  • Local vars on the stack of some thread can certainly be shared by another thread of the same process. It requires that the address of such shared vars be signaled to the other thread, but that address is surely accessible. – Martin James Jan 07 '18 at 10:54
  • 2
    @DavidC.Rankin, the "middle-aged graying guy wobbling back and forth on the screen" is Timothy "Tim" Mattson from Intel, a former CEO of the OpenMP Architecture review Board, who has worked on practically every version of the specification out there. I think he knows what he's talking about. The heap/stack terminology is not part of the OpenMP spec and is used purely as a model for the data-sharing classes defined by the standard. "The stack is private" is also a central assumption of the correctness model of multithreaded execution. – Hristo Iliev Jan 08 '18 at 07:58
  • He may have been some big-whig with lot's of alphabet-soup after his name at Intel (hopefully not responsible for the speculative execution debacle), but he sucks as an effective communicator by video. To be effective, he needs to use the magic of video to illustrate what is happening with public/private declarations, a set of good graphics will do, but to have the camera on him for the explanation is an epic-fail. (he must have failed the course in cognitive taxonomy) – David C. Rankin Jan 08 '18 at 08:06

1 Answers1

1

The wording (stack/heap) is imprecise

The OpenMP standard makes no reference1 to stack or heap in it's memory model. So I would answer your question with implementation defined. I see no reason to move the data of stack variables to the heap if they are shared. If you see by looking at pointers of shared variables, that they are on the stack, I would in fact believe that.

Even the C standard contains no reference to either stack or heap.

In my opinion you should not use the concepts that aren't part of the standards (and hence depend on implementation) to reason about correctness. Instead use storage duration and scopes.

I speculate that Tim Mattson uses stack/heap because they may be more broadly known.

1 OpenMP allows control of the stacksize for threads, but with no further reference what the stack is.

The particular example you pointed out is wrong

even if you consider the simplification:

  • automatic storage duration == "stack"
  • allocated/dynamic2 storage duration == "heap"

Your analysis is correct, the citation applies. As per 2.15.1.1, there is no predetermined data-sharing rule for objects with automatic storage duration that is not declared in a scope inside the construct. Hence it is a variable with implicitly determined data-sharing attributes.

2 Confusingly, the C standard uses "allocated storage duration" while C++ and OpenMP use "dynamic storage duration".

Zulan
  • 21,896
  • 6
  • 49
  • 109
  • The answer is to the extent of my knowledge and after carefully reading the related standard section. Normally this should go without saying, but I do not claim to generally know better than Tim Mattson. In any case he's also a human and simply may have made a mistake. – Zulan Jan 11 '18 at 16:52