Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is there a reason a thread shouldn't access other thread's stack?

I was just playing with Intel Parallel inspector on 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 bugs in your application.

I do indeed have some objects that are allocated on stack shared between threads. I don't see why this is a problem. Any hints?

like image 222
Violet Giraffe Avatar asked Jan 28 '13 20:01

Violet Giraffe


People also ask

Can a thread access another thread's stack?

Yes, a thread can modify the stack contents of another thread if they are in the same process. Stack is simply a region of memory in the process's address space and all threads of that process have same access rights to all its memory regions.

Why do threads not share a stack?

The stacks are in the same address space, but each thread is not supposed to touch the stacks that belong to other threads. Why? Well, simply because threads could not possibly share the stack, as it would inevitably lead to concurrent modification of the stack, with data corruption and crashes.

Can threads block independently from one another?

Threads in a process run independently of each other. One thread blocking shouldn't necessarily block the other threads. This is one of the main reasons that threads are used in the first place,.

Can one thread access the address space of another thread?

As you state, threads share the same address space. Thus each thread has the same access to the address space as does any other thread.


1 Answers

It's not wrong, it's just possibly wrong. Tools like Intel Parallel Inspector that provide additional diagnostics for your program must make a tradeoff between false positives and false negatives, in this case, it seems that the developers thought that accessing the stack of another thread was much more likely to be 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 signal errors in code that is correct.

The real question here is, "what is the other thread doing?" If you think, "maybe it will return from that function and the stack frame will be invalid," then you are doing parallel programming wrong. No answer about multithreaded behavior should be qualified with "maybe". You had better make sure that that thread doesn't return, for example, by making it wait on a semaphore or condition variable, or by making it join with the other threads.

Discussion

Pubby: "AFAIK it's hugely inefficient."

The only reason it would be inefficient is because you might have multiple cores modifying the same cache lines, which is the same problem you have with other kinds of shared memory.

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

If you use something in multiple threads, you use some kind of synchronization mechanism to ensure that it's not modified in an invalid way. This situation is no different.

H2CO3: Well, is there a reason you should not walk into another person's house?

If we're going to play with analogies, I'd say that the process is the house, and each of the threads are people in the house. If Dave keeps a list of chores in his room, I'll go into his room every time I need to look at the list. If he stops doing that, he'd better tell me or else I'll start writing on random pieces of paper on his desk.

Conclusion

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

like image 188
Dietrich Epp Avatar answered Oct 01 '22 09:10

Dietrich Epp