|
From: Josef W. <Jos...@gm...> - 2003-05-26 11:52:25
|
On Monday 26 May 2003 12:05, Nicholas Nethercote wrote: > [...] > Julian and I have discussed this, and AFAWCT the killer point is shadow > memory for Memcheck -- each time memory is written shadow memory is > written a few instructions before. The danger is that if two threads are > racing on a memory word, you could get a thread switch in between the > shadow write and the real write, and then your shadow memory would not > match your real memory. Sidenote (perhaps there's a misunderstanding): I thought about 2 threads running on 2 processors in parallel. There does not have any thread switching for races to occur, as without locking, interleaved memory accesses from the two threads/processors can happen in any order. As memory is a shared resource, we must use locking (atomic access to shadow and real memory). How fine should locking be done? One lock for all memory accesses kills performance. Perhaps one lock for each allocated area / or every 64 bytes of memory? This would need very fast user mode mutexes (e.g. Futexes from Linux 2.5). But all this is about problems in some specific skin. I currently wonder more about problems with the generic valgrind core (binary translation engine and runtime environment). > The problem would be avoided if we could guarantee that thread switches > only occur between basic blocks. Actually, now that I think about it, > that shouldn't be a problem with the current implementation since it does > thread scheduling itself, and never does thread switches in the middle of > a basic block. Hmm. > > As for getting rid of Valgrind's threads implementation, the best idea so > far is to intercept the clone() syscall, and have Valgrind schedule > threads itself but not do all the pthreads ops itself. This sounds But with the szenario of kernel level threads, Valgrind can't schedule them ?! > plausible, but I think the details haven't been worked out. The big > advantage would be getting rid of libpthread.so which is a source of much > complexity. The disadvantage would be that the pthreads API error > checking would disappear (I think). OK. That's usefull in general. And the full pthreads replacement can be moved to a skin. > All the other stuff you mention about making Valgrind thread-safe seem > like it shouldn't be too hard to do (famous last words...) > > All this is very Linux-centric, and a (very) long-term goal would be to > support other operating systems, but it's not at all clear how to do this. What are the most problematic Linux-centric things to get rid of? I thought a bigger problem would be to support other processor architectures. This seems an interesting goal to me as for skins, the architecture is already hidden by using the RISC-like UCodes. > Does that answer some of your questions? Thanks very much for your response. At least the dimension of this task is somewhat clearer to me now. Josef |