On Feb 20, 2008 12:42 PM, Julian Seward <[EMAIL PROTECTED]> wrote: > But anyway. A flag which says "assume all stack accesses are thread-local" > would drastically cut the number of references to be checked, and might > be a useful addition. I think old Helgrind had such a feature. The > only real difficulty is deciding for sure what is and isn't a stack access > at JIT time (basically impossible, we'd need a run-time filter too).
There are applications that share thread-allocated data over threads. Some examples: * At least with Linuxthreads, when creating a new thread by calling pthread_create(), a pointer to the thread ID is passed as the first argument to pthread_create(). Such thread ID's are typically allocated on the stack. The newly created thread then fills in this thread ID, and some time later the creator thread reads this thread ID when calling pthread_join(). So this is an example of stack-allocated data initialized by one thread and read by another thread. I did not yet check the behavior of NPTL with regard to filling in thread ID's. * There exist several high-level C++ abstractions of threads and synchronization objects. These libraries typically associate one object with each thread, one object with each mutex, etc. It is convenient when creating threads from inside main() to allocate the instances of thread objects on the stack. The data of such objects is typically accessed both by the creator and by the created thread. Bart. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
