|
From: Nicholas N. <n.n...@gm...> - 2009-02-17 23:18:00
|
On Tue, Feb 17, 2009 at 7:57 PM, Joerg Wagner <wa...@it...> wrote: > > reading from the manual I see that atomic instructions > (like lock inc, etc. on x86) are not supported by valgrind > in the sense of being emulated in a correct way. > > What is the technical reason for this? Are there any > plans to correctly handle these instructions? What > is the technical difference between handling these and > handling pthread's mutexes? Can't valgrind put something > like fake mutexes 'around' these atomic variables whenever > such an operation is used? Here's my understanding, which may not be completely right. Each original machine instruction can be translated into multiple instructions. First, because Valgrind's internal format is RISC-like, so complex instructions like the x86 'push' instruction get broken into multiple instructions. Second, because tools add more instructions. To give you an idea, code produced by Memcheck is typically 15x larger than the original code. However, Valgrind serialises multi-threaded execution anyway, so I'm not sure if losing the atomicity is a problem. Also, using software-based locks to emulate hardware-based locks would be slow, but perhaps these instructions are rare enough that it wouldn't be that bad. Nick |