Darryl Miles <[EMAIL PROTECTED]> writes: > tom fogal wrote: > > One thing I neglected to think about earlier is how one would do a > > `Can I still run?' check. There is no notification to a user process > > when a context switch comes back. > > > > Remember that valgrind instruments instructions. [snip] > Why does it need to know ?
It doesn't; I wrote this before I understood your `acquire a VG-internal lock at syscall entry' implementation, and didn't come back and edit. > > I had a long diatribe about how you essentially want the JVM's safe > > points and how ridiculously difficult it will be, as you'd have to > > write a parallel scheduler. Which I still think is true, in your > > general case of the choosing which thread to run. > > It depends what you mean by a scheduler. [snip] > I certainly wouldn't call whats proposed a parallel scheduler, it can't > make something thats not runnable (due to being blocked in the kernel) > runnable! [snip] I don't see how that's not a scheduler. Each thread essentially has a valgrind-specific state -- whether or not you'd like it to artifically suspend or not -- and valgrind should choose at various points whether or not to pause or delay the thread based on that information. But this part of the discussion is pedantic at this point. > > You really don't need that functionality though. All you want is to > > guarantee that <= 1 thread is running, at all times. > > > > A solution to your issue -- introduce a new mutex, within valgrind. > > Wrap every function you possibly can. Acquire the lock before the > > function, and release it after the function. > > You're idea of adding a mutex lock around everything, that may work. I > wouldn't be wrapping anything I would be expecting valgrind to > instrument the application/client in that way on my behalf. Yes -- I'm trying to describe how you might hack valgrind to do what you want. [snip] > Note that you could then obtain/influence threading control with the > vg_scheduler_pre_client_hook() and the vg_scheduler_post_client_hook(). Yes.. but you don't need to. The locks around the syscall already assure you that only one thread can run. However, those hooks would be the logical place to modify the internal hash table. [snip] > I think you arrive at the solution I've been discussing [...] > > So why not intercept system calls in a not so different way to your > example above, infact we can do away with the acquire() relead() stuff > and roll in into the vg_scheduler_xxxx() stuff whilst wrapping all syscalls. Valgrind already does this. Look up function wrapping in the manual. > > In this scheme, you don't get to control which thread runs. [...] > > But Yes I think I've concluded on that point. [...] > [snip -- we agree] > > > It sounds like, if you wanted to do this, you *would* need to lock at > > every instruction, since you'd need some kind of global hash table or > > other data structure which would maintain this list. > > Ah yes, now you see. Yes a memory access would involve the questions > being asked, are we interested in this extent ? do we log this access ? > is this access an application error ? > > Doesn't memcheck already do a lot of this stuff, this was the point of > valgrind to leverage on this. I'm just adding a threading twist to it. Well, it doesn't add it to an internal data structure, as far as I know .. just reports it immediately. Yes though, seems like most of the pieces you want are already there. > > By the way, have you heard of software transactional memory? ``STM''. [snip] > > I'm not sure if there are any open-source systems which implement it. > > However, an STM system must keep exactly this, except they of course > > do it to provide better parallelism than the absurdity that is > > threads. > > No thats a new one for me, I will research some as you suggest. I > disagree thread aren't absurd :) This is way off-topic -- but threads don't scale, && they're much too difficult to get right. I think it's an `Edward Lee' that has a paper on how a better approach to parallelism would be to start from determinism, and add non-determinism, instead of the reverse like we currently do with threads. Anyway with any luck most everything will be data-parallel in a decade, and threads will be this strange thing that only operating system programmers actually use. > > Thinking about those gives me the idea that you could probably avoid > > this wrapping in regions of code which could provably not r/w a shared > > variable, perhaps by knowing that the thread holds no locks. > > Euh. Just because a thread holds no locks doesn't mean that the thread > (that holds no locks) won't violate the multi-threaded design by reading > from or writing to memory it shouldn't. The reason it shouldn't is > because that location is guarded by a lock (which it didn't take before > access). Hrm, yeah, sounds like !(B => A) here, but the point still stands in general. You should come across these sorts of optimizations as you look into STM; my particular example is flawed, but this system is going to be slow, so you'll need some sort of optimization here. > > If you only need a hint, not a hard guarantee, change your wrappers to > > set and restore the thread priority instead of grab a lock. I imagine > > that'd be much cheaper. [snip] > I disagree its hard to implement a timeout, there are many such > mechanisms to do that. It's just that jumping to timeouts normally means mucking with signals, which I gather is painful in something like valgrind. I could be wrong there. > You misunderstand the point of system call interception, the point is to > pass back control to valgrind, not to modify the "error return code of a > system call" but to modify the "exit from system call and return to > caller assembly code". [...] Okay, that makes sense; the wording was a little confusing. > Now if ALL code is instrumented under emulation then there may not be a > need to intercept syscalls if we can ensure control is passed back to > valgrind BEFORE application/client code. I don't think this is possible, for the reasons mentioned at the very top of this email -- we can't know when/where a context switch will `jump back to', and the code is already translated at that point. > You completely miss the point that GDB has no support for byte granular > memory checking. Ahh, yes, I did miss that. -tom ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
