Is there a reason a thread should not access another thread stack?

Question

I just played with the Intel Parallel Inspector in my project and it displays a warning:

One or more threads in the application accessed the stack of another thread. This may indicate one or more errors in your application.

I really have some objects that are allocated on a stack shared between threads. I do not understand why this is a problem. Any clues?

Answer 1

Imagine this: a thread is executed and a method is called that has a local (stack) variable (object). It adds this object to the work queue, a queue that is processed by a separate thread.

This thread receives the element added by the first thread and accesses the object in the stack of the first thread.

What does the first thread do during this time? Perhaps he left this method and freed up this stack space. This freed space may or may not be reused. The second thread accessing the stack of the first thread may or may not work correctly, depending on the time and schedule of calls.

If you know that a stack variable will exist while the second thread processes it, then this can be safe; for example, if Thread 1 queues a stack variable and then blocks it until Thread 2 reports that it has completed processing, which is a safe operation.

A warning is issued, not an error, because it may or may not be a legitimate operation, and there is no way for the analyzer to be sure.

Answer 2

This is not so, possibly wrong. Tools such as the Intel Parallel Inspector, which provide additional diagnostics for your program, must compromise between false positives and false negatives, in which case it seems that the developers thought that accessing the stack of another thread was much more likely than an error (low false positive rate, if reported) than not (high false negative rate, if not reported).

Valgrind is another example of a tool that can correctly signal code errors.

The real question here is: "What is the other thread doing?" If you think: “it may return from this function and the stack frame will be invalid”, then you are not performing parallel programming correctly. No response about multithreaded behavior should be qualified with the help of "maybe." You must make sure that this thread does not return, for example, by forcing it to wait for a change or condition variable, or by combining with other threads.

Discussion

Pubby: "AFAIK is very inefficient."

The only reason this would be inefficient is because you may have multiple cores that change the same cache lines, which is the same problem as other types of shared memory.

Collin: How do you know that the stack stack is still good in another thread?

If you use something in multiple threads, you use some kind of synchronization mechanism to make sure that it has not been changed incorrectly. This situation is no different.

H2CO3: Well, is there a reason you should not go to another person’s house?

If we play with analogues, I would say that the process is a house, and each of the flows is people in the house. If Dave keeps a list of duties in his room, I will go to his room every time I need to look at the list. If he stops doing this, he’d better tell me, or I will start writing on random papers on my desk.

Conclusion

It is a matter of style whether the behavior of this program is acceptable or not.